When moving a C++ application to Windows 8/Windows Phone 8 the first consideration is the user interface. Few, if any, applications have a user interface that is appropriate for the touch-centric UI that Windows 8 showcases. There are four options for the UI layer:
- DirectX with C++
- XAML with C++
- XAML with .NET
- HTML5 over Windows RT
Since the UI needs to be rewritten rather than ported, coverage of these technologies it outside the scope of this report.
Many Win32 and COM APIs are simply not available. Others will be restricted, so even if the API exists it won’t necessarily be able to do the same things that it used to do. In addition to security, many of these API restrictions were made because they have a negative impact on battery life or don’t match the new application life cycle models. Furthermore, all of the GDI subsystem is off limits.
Unlike traditional COM, developers cannot define their own contracts for cross-application communication. And with socket restrictions simply listening to a local port will not work either. The basic theory behind this decision is that WinRT applications should be completely isolated. This means that developers cannot install sets of applications at one time.
To determine what APIs are no longer allowed developers can use the WINAPI_FAMILY_PARTITION macro to get compiler errors. This can be a somewhat frustrating process because the error messages about missing structs can distract developers away from the forbidden APIs calls that use said structs.
Tarek Madkour of Microsoft recommends that developers porting existing libraries to use the Windows Application Certification Kit instead of the macro. To do this, create a new XAML based application and reference all of the libraries you want to port. You then need to run it once so that it is deployed on the computer. Next you run the Certification Kit against the application to generate a list of API calls that need to be replaced or removed.
Another resource in this area is the Alternatives to Windows APIs in Windows Store apps list.
Threading
The classic CreateThread API call is not supported in WinRT. For general use the WinRT ThreadPool serves that role. A major down side of the WinRT ThreadPool is that it is not supported in standard Windows applications. The other options that follow do not have this restriction.
Parallel Patterns Library Tasks is another option for those looking for a high level of abstraction.
For lower level access ISO C++ std::thread and std::future are allowed. In a broader context, Microsoft intends to support standard C++ across all of their devices and operating systems.
The lowest level option is the VC++ Runtime’s _beginthread function. According to Tarek , this has the “maximum ability to shoot your foot”. NOTE: Contrary to the Microsoft presentation, the link above says that this API is not supported.
Async
Much like C# and VB, C++ developers targeting Windows 8 should familiarize themselves with the new async patterns and lambda expression syntax.
Exposing Libraries
While most libraries can be written in straight C++, anything that needs to be exposed to other languages should be exposed as a WinRT component using C++/CX. Performance wise this is going to be slower than normal C++ linking so it shouldn’t be used by C++ applications consuming your library.
Neither C nor C++/CLI will be supported in WinRT applications.