Katherine Barrios

The State of WinCE Support in Qt5

Published Tuesday July 30th, 2013
17 Comments on The State of WinCE Support in Qt5
Posted in Uncategorized

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
# This is just a template for creating WEC7 mkspecs for ARM targets
# Replace the SDK name with actual SDK name.


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

_WIN32_WCE=0x700 $$CE_ARCH _AMRV7_ armv7 _ARM_

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_OPENVG       = libopenvg.lib
QMAKE_LIBS_OPENGL_ES2   = libEGL.lib libGLESv2.lib

QMAKE_RC                = rc


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.


Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Uncategorized


Wilbert says:


Patrick says:

Banks care about it (a surprising number of ATMs run WinCE).

People who write industrial control systems care about it (scary, yes?).

So people with Lots of Money to Spend(tm) care about it, so it’s worth supporting right? Because it makes money.

This is why the commercial services side of things are putting the effort in.

Aki says:

He must be proud.

David says:


I really appreciate your open dialogue policy as sometimes there are legitimate concerns and grievances, but comments like Wilbert’s are really unwarranted and should not be allowed to pollute this forum. Please consider filtering out such juvenile opinions .

mercyril says:

I am very glad to see your job, i am very interested by win ce platform support with qt5.
Win CE has a big part in industrial device and so QT5 for Win CE should be very appreciated.

Slartibart says:

Who let the trolls in?

Jakub says:

Great! I would like to see support for WinCE 5 and WinCE 6 as the lot of our clients use mobile terminals with barcode scanners and WinCE onboard. I was trying to compile Qt4.8.4,Qt5.0, Qt5.0.1 and Qt5.1 for WinCE but with no luck. Also I was trying to get work QtQuick from Qt5.1 on iOS, but with no luck too.

Kostya Maslyuk says:

I’m interested in Windows Mobile too.

Qt 4.8 series should compile fine for WMб, though at runtime you would get exceptions related to static data initialization order. Start thread on forum and invite me, if you wish.

Jakub says:

I was managed to compile Qt 5.1 for WindowsCE and even deploy example project to WinCE Emulator. The problem is that appliaction crashes immediately afet start and doesn’t throw any exception or error. Somehow I can compile only release libraries, so I can’t even attach to the application with debugger.

Recently I was testing Qt for iOS with this solution:

I changed few configure options and Qt for WinCE was successfully compiled. You just need to remove all OpenGL entries from the *.pro files, because -no-opengl doesn’t work and it will block Your compilation. You will also get ‘snprintf is undefined’ error, so change it to sprintf.

Why can’t you build a debug version? And if you need debug symbols you can use -force-debug-info to generate them for a release build.

Laszlo Papp says:

Well done!

QtSerialPort used to work at some point as well, but unfortunately we do not have the manpower anymore to update it alongside the new changes.

It would be nice if someone could help us with that one. We would be supportive as much as we can.

mm says:

How about porting to WEC2013. aka WinCE8.?
The compiler and development tools suppose to improved and on-par with WIndows Desktop.
Perfect opportunity for Digia to fill a huge gap in Windows CE middleware.

We are looking for a device to check whats needed to port Qt5 to WEC2013. It finally has a modern compiler and a lot less restrictions. Can’t say when this will happen, but we definitely want to investigate the
possibility of the port.

mm says:

Boot to Qt on WEC2013 device would be great too.
There are a number of WEC2013 BSP available soon for real devices such as the Freescale iMX6 Saberlight kit.

It’s always refreshing to see the Qt philosophy of true cross-platforming at work. Qt everywhere!

huellif says:

Why for Windows CE and not for Symbian???really a shame …

Tosog says:

Hello, thanks for your research. I also tried to compile QT 5.1 for WinCE 6 (R3) but i had no luck using the default settings. Finally I’ve managed to compile for WinCE but i had to do a lot of manual modifications to configure.exe, Makefile.Release files, some source files (SS3 support) etc.
I only see examples using WCE7, but not with WinCE6 R3. Is this supposed to work?
And whats the “official” statement about WinCE6. Is this considered a “supported plattform” or not? In the supported platforms list, only “Windows Embedded Compact and Standard” are supported, but not WinCE 6.

Commenting closed.

Get started today with Qt Download now