The State of WinCE Support in Qt5

Today, we are happy to have a blog post from our Digia, Qt Partner, KDAB. Bjoern Breitmeyer gives us an update on KDAB's work on  Qt for WinCE.
-----------------------------------------------------------

When Qt5 was released official support for Windows CE was initially dropped. As KDAB's customers still showed a lot of interest in the platform we decided to step forward to fill the gap. This resulted in my coworker Andreas Holzammer and myself starting to port CE support from Qt4 into Qt5 and recently I became the official Qt maintainer for WindowsCE.

The biggest effort was to get the new windows platform support plugin to support Windows CE. We got widget-based applications working relatively quickly and this was soon followed by QML1 support. The OpenGL support had to follow for QtQuick2. Another big roadblock was the porting of v8 to WindowsCE. As the javascript engine uses just-in-time compilation we faced issues that were deeply processor and os specific. The one big problem was that QML2 applications would crash if bindings were used, not initially but after a while. It was a scary thing to explore as the just-in-time compiler would create weird and different backtraces.

After lots of debugging we found out that the binding optimization, that would kick in after a binding was used the third time, caused crashes. With some digging it became clear that Microsoft used a different ABI for WindowsCE on Arm and that v8 didn't support that, it expected a compiler optimization that was not done by the CE compiler. Following some debugging and testing, we decided that the binding optimization that triggers the crashing codepath could be disabled on WindowsCE, which is why you can actually create and run QML2 applications on WindowsCE.

To compile Qt4 for WindowsCE was a hassle which required users to configure with the host environment and, after configuring, use the CheckSDK tool to set the environment for the cross compile build. This seemed rather inconvenient so we decided to integrate the CheckSDK tool into qmake, which creates self contained Makefiles. All you need to set is the Visual Studio 2008 professional environment and have the SDK specified in your customized WindowsCE makespec. QMake will then build the host tools with the host environment and the cross build with the CE environment of the set SDK.

A small example for the beagle board - xM mkspec with a test BSP from Adeneo:
------------------------------------------------------------------------
# qmake configuration for Windows Embedded Compact 7 with VS2008 on ARM
targets
#
# This is just a template for creating WEC7 mkspecs for ARM targets
# Replace the SDK name with actual SDK name.

include(../common/wince/qmake.conf)

CE_SDK                  = BeagleBoard-xM - WEC7   # replace with actual SDK
name
CE_ARCH                 = ARMv4I
QT_CONFIG               -= accessibility

DEFINES                 += QT_NO_ACCESSIBILITY QT_NO_CLIPBOARD
QT_NO_NATIVE_GESTURES QT_NOSTANDARDSHELL_UI_MODEL _CRT_SECURE_NO_DEPRECATE
_WIN32_WCE=0x700 $$CE_ARCH _AMRV7_ armv7 _ARM_

QMAKE_LFLAGS_CONSOLE    = /SUBSYSTEM:WINDOWSCE,7.00 /MACHINE:THUMB
/ENTRY:mainACRTStartup
QMAKE_LFLAGS_WINDOWS    = /SUBSYSTEM:WINDOWSCE,7.00 /MACHINE:THUMB
QMAKE_LFLAGS_DLL        = /SUBSYSTEM:WINDOWSCE,7.00 /MACHINE:THUMB /DLL
/SAFESEH:NO
QMAKE_LIBFLAGS_RELEASE  = /LTCG
QMAKE_LIBS              = corelibc.lib coredll.lib
QMAKE_LIBS_CORE         = corelibc.lib ole32.lib oleaut32.lib uuid.lib
commctrl.lib coredll.lib winsock.lib
QMAKE_LIBS_GUI          = ceshell.lib ole32.lib $$QMAKE_LIBS_CORE
QMAKE_LIBS_NETWORK      = ws2.lib $$QMAKE_LIBS_GUI
QMAKE_LIBS_OPENGL       =
QMAKE_LIBS_COMPAT       =
QMAKE_LIBS_OPENVG       = libopenvg.lib
QMAKE_LIBS_OPENGL_ES2   = libEGL.lib libGLESv2.lib

QMAKE_RC                = rc

QMAKE_COMPILER_DEFINES  -= _MSC_VER=1400
QMAKE_COMPILER_DEFINES  += _MSC_VER=1500
-------------------------------------------------------------------------------

If CE_ARCH and CE_SDK is set you just need to specify the mkspec as -xplatform in configure.

This has the great advantage that you just need the Visual Studio 2008 environment set, along with the qmake of the Qt5 for WindowsCE build in your path, and you can call qmake + nmake to build your project for WindowsCE. No special environment needs to be setup. In the future we would like to have a linux-like setup where you can use the mkspec and just set some device specific parameters like SDK and Arch in configure.

With the release of Qt5.1 it is possible to build for WindowsCE. However, there are several things to take into consideration. The first and most important one is that Windows CE5 and therefore Windows Mobile 6 are not supported by Qt5. It might be added in the future but for now it's considered not worth the effort. Nevertheless, Windows Embedded Compact 6 and 7 are supported. Now it has been released, we will evaluate adding Embedded Compact 2013. Building Qt with -nomake examples and -nomake demos is recommended as some of them may not build due to missing features on WindowsCE, causing the Qt build to break. You can build them afterwards with qmake + nmake if you need to and they can run on WindowsCE. And finally there is a reduced list of supported modules, which are:

- qtbase
- qtjsbackend
- qtdeclarative
- qtscript
- qtquick1
- qtsvg
- qtgraphicaleffects
- qtimageformats
- qtxmlpatterns

To elaborate a bit more on the missing important modules.

- Webkit: Wekbit2 requires ICU and building ICU for WindowsCE is a difficult task as the build system is highly linux-centric. We managed to get it working, but without an upstream solution in either Qt or ICU this is hard to support. That means its not likely to become available out of the box in the near future without additional investment.

- Multimedia: There are patches on gerrit that can re-enable basic QtMultimedia support. How far this will be able to go only time can tell.

- Tools: The host tools are hard to support as there is no host build of Qt, it's just easier to use the tools from a Desktop Qt. There are remote CE tools that might be re-enabled in the future as they could be very useful.

Some of the other modules might work too, but are untested right now.

Unfortunately one issue did creep into the Qt5.1 release. There is an assert hitting if you use widgets in debug mode and with the native font engine. Using the freetype font rendering engine or use a release build still allows you to run your applications. This bug has already been fixed and will be gone in 5.1.1

We will continue to improve the support in Qt 5 for embedded Windows platforms according to our customers' needs and priorities. If you have input or feedback, please get in touch.

---------------------