Porting Qt 5 to Windows Runtime (WinRT/Windows 8 Metro)
Qt for WinRT is now in the qtbase dev branch. See http://qt-project.org/wiki/WinRTBuild for how to build it.
While WinRT is, in many ways, the same old Windows, many APIs have been replaced or removed [msdn.microsoft.com]. As such, most of Qt’s Windows private implementations (PIMPLs) require refactoring [msdn.microsoft.com]. In other words, Windows Store applications (Appx apps) have sandbox requirements that suggest a considerable overhaul of Qt’s Windows internals.
Note: this page was created to track some of the finer details of the porting needs. See Qt 5 on Windows 8 and Metro UI for the rest of the story.
A new platform
The closest thing to WinRT in Qt’s supported platform list is probably WinCE. Not insomuch as the platforms are similar, but rather how WinCE’s private implementation is done: it uses the Windows’ implementation with scattered #ifdef regions. As WinRT probably requires a bit more drastic set of changes than WinCE, there will likely be places for both #ifdef solutions as well as separate .cpp files.
- There needs to be a new os #define, Q_OS_WINRT
- It should be considered if architecture is needed as well: WINRT32, WINRT64, WINRTARM…
Initially it seemed like the Windows Phone 8 API would not differ much from WinRT API. Nevertheless it turned out that Windows Phone 8 supports API which is not available on WinRT (see winsock2 for example). So a Windows Phone 8 port does not automatically mean a WinRT port but the other way around might be possible.
Technical objectives of the port
- Create new QPA plugin(s) that can handle as much of the platform-specific details as possible.
- Base the remaining platform-specifics on the existing Windows implementation, creating new code or patches where needed.
Technical details of the port
- When including files from the Windows SDK [msdn.microsoft.com], the WIN_API_FAMILY define can be used to hide parts that are not available to Windows Store applications. Obtaining a clean compile with WIN_API_FAMILY=WINAPI_FAMILY_APP is the end goal, but there are many backends which need to be rewritten in order to do this.
- Beyond API changes, there are also a considerable number of POSIX C-runtime functions that are now completely unsupported under WinRT [msdn.microsoft.com].
- Windows Store Applications (Appx) are compiled with the /ZW switch, which enables metadata and therefore doesn’t support fun stuff like external C libraries. This shouldn’t be an issue as long as Qt itself is compiled without the flag (and the apps are).
- As a consequence of the above requirements, Qt uses different compiler switches, headers, & libs for the Qt tools. Hence, we can only support the WinRT mkspec as an -xplatform. Furthermore, it should likely have variants winrt-x86, winrt-x64, winrt-armv7, etc.
- To achieve the best compatibility/consistency with C++ standards as well as support for code editors, only WRL templates [msdn.microsoft.com] should be used when writing platform code for WinRT. No C++/CX extensions should be used.
High-level Approach to Porting
- For classes which “_qpa” PIMPLs are available, these should be used.
- In simple “_win” PIMPL cases, #ifdef regions can be used.
- In more complex situations (i.e. where a complete rewrite is needed), a “_winrt” PIMPL should be created.
This list is intended to track the porting progress by module and file. If you have worked with one of these, please update its status.
qtbase (QtCore, QtGui, QtNetwork, QtPrintingSupport)
There are about 30 C++ files containing one or more Windows PIMPLs in qtbase.
moc cannot cope with #ifdef WINAPI_FAMILY==WINAPI_FAMILY_FOO
moc’s preprocessor has to be enhanced to be able to deal with these constructs
To Widget or Not to Widget?
Given the canvas-like, touch-oriented nature of the Metro environment, widgets (and modules which depend on them) should be considered low priority. That is not to say that they have no place in Qt WinRT apps, but it is to say that configuring with —no-widgets helps us focus on more important tasks.
This is a static library that is linked in Windows applications which boostraps the entry point. This is actually a good fit for WinRT as well, which requires that the application run is launched in one thread but actually executes in another. Progress here [qt.gitorious.org]
Use qsystemtrayicon_qpa.cpp instead. QtWidgets, low-priority.
From QtPrintSupport. Reimplement with Windows.Graphics.Printing [msdn.microsoft.com]
Unsupported headers: Winsock2.h
Unsupported libs: Ws2_32
Reimplement with Windows.Networking.Sockets [msdn.microsoft.com]
Unsupported headers: Wingdi.h
Unsupported libs: Gdi32
Reimplement with Windows.Graphics.Imaging [msdn.microsoft.com]
Likely can remain with minor modifications. GetLocaleEx (as opposed to GetLocale) is supported under WinRT, so #ifdefs likely sufficient.
Appears that only GetModuleHandleW() needs replacement. Everything else should work.
Most synchronization features remain available in WinRT. WaitForSingleObject() should be replaced with WaitForSingleObjectEx [msdn.microsoft.com].
Some threading APIs remain in WinRT, but others require reimplementation. Needs more investigation.
Change WaitForSingleObject() to WaitForSingleObjectEx [msdn.microsoft.com], otherwise appears to be fine.
Reimplement using LoadPackagedLibrary [msdn.microsoft.com] and friends.
CreateSemaphoreEx [msdn.microsoft.com] can be used to replace CreateSemaphore().
Shared memory is not supported in WinRT and apps are sandboxed… possibly not supportable.
Reimplement using WRL
Mostly filled with unneeded message types. Reimplement a minimal “winrt” version.
Relies on the unsupported SHGetSpecialFolderPath() call. Possibly can be reimplemented with Windows.Storage.StorageFolder/Windows.Storage.Search
Unsupported libraries: Advapi32
As the registry is not supported in WinRT, reimplement with Windows.Storage.ApplicationData [msdn.microsoft.com]
Named pipes are not supported in WinRT, which is the backbone of the Windows QProcess PIMPL. Some functions, such as pid(), should remain working.
Reimplement with Windows.Storage.StorageFile [msdn.microsoft.com]
One (likely disturbing to some) possibility would be to sidestep WebKit and use WinRT’s built-in IE10 engine for QML WebViews instead.