WinRT: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Decode HTML entity names)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
'''This page is here for historical reasons, but the port to WinRT is largely complete.'''
'''This page is here for historical reasons, but the port to WinRT is largely complete.'''


=Qt for WinRT=
= Qt for WinRT =


==Qt 5.3 Documentation==
== Qt 5.3 Documentation ==


Qt for WinRT is part of the Qt 5.3 release and the following pages contain its documentation:
Qt for WinRT is part of the Qt 5.3 release and the following pages contain its documentation:


* http://doc.qt.io/qt-5/winrt-support.html – reference documentation
* http://doc.qt.io/qt-5/winrt-support.html - reference documentation
* [[WinRTBuild|http://wiki.qt.io/WinRTBuild]] – how to build Qt for WinRT
* http://wiki.qt.io/WinRTBuild - how to build Qt for WinRT


=Porting Qt 5 to Windows Runtime (WinRT/Windows 8 Metro)=
= Porting Qt 5 to Windows Runtime (WinRT/Windows 8 Metro) =


While WinRT is, in many ways, the same old Windows, many <span class="caps">API</span>s have been [http://msdn.microsoft.com/en-us/library/windows/apps/br211377.aspx replaced or removed] ''[msdn.microsoft.com]''. As such, most of Qt’s Windows private implementations (<span class="caps">PIMPL</span>s) require [http://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx 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.
While WinRT is, in many ways, the same old Windows, many APIs have been [http://msdn.microsoft.com/en-us/library/windows/apps/br211377.aspx replaced or removed]. As such, most of Qt's Windows private implementations (PIMPLs) require [http://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx refactoring]. 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|Qt 5 on Windows 8 and Metro UI]] for the rest of the story.
'''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==
== 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.


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
* There needs to be a new os #define, Q_OS_WINRT
* It should be considered if architecture is needed as well: WINRT32, WINRT64, <span class="caps">WINRTARM</span>…
* It should be considered if architecture is needed as well: WINRT32, WINRT64, WINRTARM…


Initially it seemed like the Windows Phone 8 <span class="caps">API</span> would not differ much from WinRT <span class="caps">API</span>. Nevertheless it turned out that Windows Phone 8 supports <span class="caps">API</span> 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.
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==
== Technical objectives of the port ==


* Create new [[Qt-Platform-Abstraction|<span class="caps">QPA</span>]] plugin(s) that can handle as much of the platform-specific details as possible.
* Create new [[Qt Platform Abstraction |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.
* Base the remaining platform-specifics on the existing Windows implementation, creating new code or patches where needed.


==Technical details of the port==
== Technical details of the port ==
 
* When including files from the [http://msdn.microsoft.com/en-us/windows/hardware/hh852363.aspx Windows <span class="caps">SDK</span>] ''[msdn.microsoft.com]'', the <span class="caps">WIN</span>_API_FAMILY define can be used to hide parts that are not available to Windows Store applications. Obtaining a clean compile with <span class="caps">WIN</span>_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 <span class="caps">API</span> changes, there are also a considerable number of <span class="caps">POSIX</span> C-runtime functions that are now completely unsupported under [http://msdn.microsoft.com/en-us/library/hh674596.aspx 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, &amp; 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 [http://msdn.microsoft.com/en-us/library/windows/apps/hh438466.aspx <span class="caps">WRL</span> 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” <span class="caps">PIMPL</span>s are available, these should be used.
* When including files from the [http://msdn.microsoft.com/en-us/windows/hardware/hh852363.aspx Windows SDK], 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.
* In simple “_win” <span class="caps">PIMPL</span> cases, #ifdef regions can be used.
* Beyond API changes, there are also a considerable number of POSIX C-runtime functions that are now completely unsupported under [http://msdn.microsoft.com/en-us/library/hh674596.aspx WinRT].
* In more complex situations (i.e. where a complete rewrite is needed), a “_winrt” <span class="caps">PIMPL</span> should be created.
* 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 [http://msdn.microsoft.com/en-us/library/windows/apps/hh438466.aspx WRL templates] should be used when writing platform code for WinRT. No C+''/CX extensions should be used.


==Porting Status==
== 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.


== Porting Status ==
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.
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)===
=== qtbase (QtCore, QtGui, QtNetwork, QtPrintingSupport) ===
 
There are about 30 C''+ files containing one or more Windows PIMPLs in qtbase.
There are about 30 C++ files containing one or more Windows <span class="caps">PIMPL</span>s in qtbase.
 
'''moc cannot cope with #ifdef <span class="caps">WINAPI</span>_FAMILY==WINAPI_FAMILY_FOO'''<br /> moc’s preprocessor has to be enhanced to be able to deal with these constructs


'''To Widget or Not to Widget?'''<br /> 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.
'''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


'''qwinmain'''<br /> 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 [https://qt.gitorious.org/qt/qtbase/trees/winrt/src/winmain here] ''[qt.gitorious.org]''
'''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.


'''qsystemtrayicon_win.cpp'''<br /> Use qsystemtrayicon_qpa.cpp instead. QtWidgets, low-priority.<br />'''Done'''
'''qwinmain'''
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 [https://qt.gitorious.org/qt/qtbase/trees/winrt/src/winmain here]


'''qwizard_win.cpp'''<br /> QtWidgets, low-priority.<br />'''Done'''
'''qsystemtrayicon_win.cpp'''
Use qsystemtrayicon_qpa.cpp instead. QtWidgets, low-priority.
'''Done'''


'''qprintengine_win.cpp'''<br />'''qprintdialog_win.cpp'''<br />'''qpagesetupdialog_win.cpp'''<br /> From QtPrintSupport. Reimplement with [http://msdn.microsoft.com/en-us/library/windows/apps/windows.graphics.printing.aspx Windows.Graphics.Printing] ''[msdn.microsoft.com]''
'''qwizard_win.cpp'''
QtWidgets, low-priority.
'''Done'''


'''qnativesocketengine_win.cpp'''<br />'''qlocalsocket_win.cpp'''<br />'''qlocalserver_win.cpp'''<br />'''qnetworkproxy_win.cpp'''<br />'''qhostinfo_win.cpp'''<br />'''qdnslookup_win.cpp'''<br /> Unsupported headers: Winsock2.h<br /> Unsupported libs: Ws2_32<br /> Reimplement with [http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.sockets.aspx Windows.Networking.Sockets] ''[msdn.microsoft.com]''
'''qprintengine_win.cpp'''
'''qprintdialog_win.cpp'''
'''qpagesetupdialog_win.cpp'''
From QtPrintSupport. Reimplement with [http://msdn.microsoft.com/en-us/library/windows/apps/windows.graphics.printing.aspx Windows.Graphics.Printing]


'''qpixmap_win.cpp'''<br /> Unsupported headers: Wingdi.h<br /> Unsupported libs: Gdi32<br /> Reimplement with [http://msdn.microsoft.com/en-us/library/windows/apps/windows.graphics.imaging.aspx Windows.Graphics.Imaging] ''[msdn.microsoft.com]''
'''qnativesocketengine_win.cpp'''
'''qlocalsocket_win.cpp'''
'''qlocalserver_win.cpp'''
'''qnetworkproxy_win.cpp'''
'''qhostinfo_win.cpp'''
'''qdnslookup_win.cpp'''
Unsupported headers: Winsock2.h
Unsupported libs: Ws2_32
Reimplement with [http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.sockets.aspx Windows.Networking.Sockets]


'''qlocale_win.cpp'''<br /> Likely can remain with minor modifications. GetLocaleEx (as opposed to GetLocale) is supported under WinRT, so #ifdefs likely sufficient.<br />'''Done'''
'''qpixmap_win.cpp'''
Unsupported headers: Wingdi.h
Unsupported libs: Gdi32
Reimplement with [http://msdn.microsoft.com/en-us/library/windows/apps/windows.graphics.imaging.aspx Windows.Graphics.Imaging]


'''qelapsedtimer_win.cpp'''<br /> Appears that only GetModuleHandleW() needs replacement. Everything else should work.<br />'''Done'''
'''qlocale_win.cpp'''
Likely can remain with minor modifications. GetLocaleEx (as opposed to GetLocale) is supported under WinRT, so #ifdefs likely sufficient.
'''Done'''


'''qwaitcondition_win.cpp'''<br /> Most synchronization features remain available in WinRT. WaitForSingleObject() should be replaced with [http://msdn.microsoft.com/en-us/library/windows/desktop/ms687036.aspx WaitForSingleObjectEx] ''[msdn.microsoft.com]''.<br />'''Done'''
'''qelapsedtimer_win.cpp'''
Appears that only GetModuleHandleW() needs replacement. Everything else should work.
'''Done'''


'''qthread_win.cpp'''<br /> Some threading <span class="caps">API</span>s remain in WinRT, but others require reimplementation. Needs more investigation.
'''qwaitcondition_win.cpp'''
Most synchronization features remain available in WinRT. WaitForSingleObject() should be replaced with [http://msdn.microsoft.com/en-us/library/windows/desktop/ms687036.aspx WaitForSingleObjectEx].
'''Done'''


'''qmutex_win.cpp'''<br /> Change WaitForSingleObject() to [http://msdn.microsoft.com/en-us/library/windows/desktop/ms687036.aspx WaitForSingleObjectEx] ''[msdn.microsoft.com]'', otherwise appears to be fine.<br />'''Done'''
'''qthread_win.cpp'''
Some threading APIs remain in WinRT, but others require reimplementation. Needs more investigation.


'''qlibrary_win.cpp'''<br /> Reimplement using [http://msdn.microsoft.com/en-us/library/windows/desktop/hh447159.aspx LoadPackagedLibrary] ''[msdn.microsoft.com]'' and friends.<br />'''Done'''
'''qmutex_win.cpp'''
Change WaitForSingleObject() to [http://msdn.microsoft.com/en-us/library/windows/desktop/ms687036.aspx WaitForSingleObjectEx], otherwise appears to be fine.
'''Done'''


'''qsystemsemaphore_win.cpp'''<br />[http://msdn.microsoft.com/en-us/library/windows/desktop/ms682446.aspx CreateSemaphoreEx] ''[msdn.microsoft.com]'' can be used to replace CreateSemaphore().<br />'''Done'''
'''qlibrary_win.cpp'''
Reimplement using [http://msdn.microsoft.com/en-us/library/windows/desktop/hh447159.aspx LoadPackagedLibrary] and friends.
'''Done'''


'''qsharedmemory_win.cpp'''<br /> Shared memory is not supported in WinRT and apps are sandboxed… possibly not supportable.
'''qsystemsemaphore_win.cpp'''
[http://msdn.microsoft.com/en-us/library/windows/desktop/ms682446.aspx CreateSemaphoreEx] can be used to replace CreateSemaphore().
'''Done'''


'''qeventdispatcher_win.cpp'''<br /> Reimplement using <span class="caps">WRL</span>
'''qsharedmemory_win.cpp'''
Shared memory is not supported in WinRT and apps are sandboxed… possibly not supportable.


'''qcoreapplication_win.cpp'''<br /> Mostly filled with unneeded message types. Reimplement a minimal “winrt” version.
'''qeventdispatcher_win.cpp'''
Reimplement using WRL


'''qstandardpaths_win.cpp'''<br /> Relies on the unsupported SHGetSpecialFolderPath() call. Possibly can be reimplemented with Windows.Storage.StorageFolder/Windows.Storage.Search
'''qcoreapplication_win.cpp'''
Mostly filled with unneeded message types. Reimplement a minimal "winrt" version.


'''qsettings_win.cpp'''<br /> Unsupported libraries: Advapi32<br /> As the registry is not supported in WinRT, reimplement with [http://msdn.microsoft.com/en-us/library/windows/apps/br241587.aspx Windows.Storage.ApplicationData] ''[msdn.microsoft.com]''
'''qstandardpaths_win.cpp'''
Relies on the unsupported SHGetSpecialFolderPath() call. Possibly can be reimplemented with Windows.Storage.StorageFolder/Windows.Storage.Search


'''qprocess_win.cpp'''<br /> Named pipes are not supported in WinRT, which is the backbone of the Windows QProcess <span class="caps">PIMPL</span>. Some functions, such as pid(), should remain working.
'''qsettings_win.cpp'''
Unsupported libraries: Advapi32
As the registry is not supported in WinRT, reimplement with [http://msdn.microsoft.com/en-us/library/windows/apps/br241587.aspx Windows.Storage.ApplicationData]


'''qfsfileengine_win.cpp'''<br />'''qfilesystemiterator_win.cpp'''<br />'''qfilesystemengine_win.cpp'''<br /> Reimplement with [http://msdn.microsoft.com/library/windows/apps/BR227171 Windows.Storage.StorageFile] ''[msdn.microsoft.com]''
'''qprocess_win.cpp'''
Named pipes are not supported in WinRT, which is the backbone of the Windows QProcess PIMPL. Some functions, such as pid(), should remain working.


===QtQml===
'''qfsfileengine_win.cpp'''
'''qfilesystemiterator_win.cpp'''
'''qfilesystemengine_win.cpp'''
Reimplement with [http://msdn.microsoft.com/library/windows/apps/BR227171 Windows.Storage.StorageFile]


===QtQuick===
=== QtQml ===


===qtjsbackend===
=== QtQuick ===


===QtWebKit===
=== qtjsbackend ===


One (likely disturbing to some) possibility would be to sidestep WebKit and use WinRT’s built-in IE10 engine for <span class="caps">QML</span> WebViews instead.
=== QtWebKit ===

Latest revision as of 17:56, 12 March 2015

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

This page is here for historical reasons, but the port to WinRT is largely complete.

Qt for WinRT

Qt 5.3 Documentation

Qt for WinRT is part of the Qt 5.3 release and the following pages contain its documentation:

Porting Qt 5 to Windows Runtime (WinRT/Windows 8 Metro)

While WinRT is, in many ways, the same old Windows, many APIs have been replaced or removed. As such, most of Qt's Windows private implementations (PIMPLs) require refactoring. 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, 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.
  • 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 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.

Porting Status

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.

qwinmain 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

qsystemtrayicon_win.cpp Use qsystemtrayicon_qpa.cpp instead. QtWidgets, low-priority. Done

qwizard_win.cpp QtWidgets, low-priority. Done

qprintengine_win.cpp qprintdialog_win.cpp qpagesetupdialog_win.cpp From QtPrintSupport. Reimplement with Windows.Graphics.Printing

qnativesocketengine_win.cpp qlocalsocket_win.cpp qlocalserver_win.cpp qnetworkproxy_win.cpp qhostinfo_win.cpp qdnslookup_win.cpp Unsupported headers: Winsock2.h Unsupported libs: Ws2_32 Reimplement with Windows.Networking.Sockets

qpixmap_win.cpp Unsupported headers: Wingdi.h Unsupported libs: Gdi32 Reimplement with Windows.Graphics.Imaging

qlocale_win.cpp Likely can remain with minor modifications. GetLocaleEx (as opposed to GetLocale) is supported under WinRT, so #ifdefs likely sufficient. Done

qelapsedtimer_win.cpp Appears that only GetModuleHandleW() needs replacement. Everything else should work. Done

qwaitcondition_win.cpp Most synchronization features remain available in WinRT. WaitForSingleObject() should be replaced with WaitForSingleObjectEx. Done

qthread_win.cpp Some threading APIs remain in WinRT, but others require reimplementation. Needs more investigation.

qmutex_win.cpp Change WaitForSingleObject() to WaitForSingleObjectEx, otherwise appears to be fine. Done

qlibrary_win.cpp Reimplement using LoadPackagedLibrary and friends. Done

qsystemsemaphore_win.cpp CreateSemaphoreEx can be used to replace CreateSemaphore(). Done

qsharedmemory_win.cpp Shared memory is not supported in WinRT and apps are sandboxed… possibly not supportable.

qeventdispatcher_win.cpp Reimplement using WRL

qcoreapplication_win.cpp Mostly filled with unneeded message types. Reimplement a minimal "winrt" version.

qstandardpaths_win.cpp Relies on the unsupported SHGetSpecialFolderPath() call. Possibly can be reimplemented with Windows.Storage.StorageFolder/Windows.Storage.Search

qsettings_win.cpp Unsupported libraries: Advapi32 As the registry is not supported in WinRT, reimplement with Windows.Storage.ApplicationData

qprocess_win.cpp Named pipes are not supported in WinRT, which is the backbone of the Windows QProcess PIMPL. Some functions, such as pid(), should remain working.

qfsfileengine_win.cpp qfilesystemiterator_win.cpp qfilesystemengine_win.cpp Reimplement with Windows.Storage.StorageFile

QtQml

QtQuick

qtjsbackend

QtWebKit

Retrieved from "https://wiki.qt.io/index.php?title=WinRT&oldid=13724"