Bringing the magic of Qt to Windows Runtime

Published Tuesday March 25th, 2014 | by

We’ve been hard at work on the Windows Runtime (WinRT) port and it’s about time we share a bit with all of you. For Qt 5.3, we’re releasing the WinRT port as Beta quality, with most of the Qt Essentials modules in functional form (including QML & Quick). We also have preliminary tooling support, so you can get started on WinRT as quickly as you would on any other supported Qt platform.

An API for modern devices

As a reminder, Windows Runtime is a new API largely tied to Windows Store Apps, or applications which run within the Modern UI environment. It has C++ bindings (among other languages), and can be used on Windows 8, Windows Phone 8, and Windows RT – running the gamut from budget smartphones to high-end PCs. That’s a lot of devices.

One of the most important things for us (and many of you) has been getting Qt Quick working smoothly on the platform. As you might guess, there are some limitations to getting such a stack working here. For one, the memory APIs which are commonly used by just-in-time (JIT) compilers (such as in QtQml’s virtual machine engine) are restricted and cannot be used by apps in the Windows Store (this is, of course, for platform security reasons; the same restriction is in place on iOS). Fortunately, the V4 virtual machine which premiered in Qt 5.2 has solved this problem swimmingly, allowing WinRT to utilize the interpreted codepath for these types of operations (albeit at the cost of some less optimal code execution speed).
Read more…


Posted in cross-platform, integration, OpenGL, QPA, Qt Quick 2, Windows, WinRT

Experimental Version of Qt Creator’s WinRT Plugin

Published Wednesday March 5th, 2014 | by

As many of you might have heard, we released Qt Creator’s 3.1 beta version on March 4th. While a lot of new things were mentioned in the blog post here, we still have something more to tell you about. The first version of our new WinRT plugin is now up and running – and already available in Qt Creator 3.1 beta. While there are still things that do not work yet, it is a great start and a lot of functionality is already covered.

The main features that already work nicely are:

  • Registration of Windows Runtime and Windows Phone Qt versions
  • Support for Windows Runtime and Windows Phone Kits
  • Building of Windows Runtime and Windows Phone applications
  • Running of applications for Windows Runtime and Windows Phone via Qt Creator’s “Run” button

Read more…


Posted in Mobile, Qt, QtCreator, Windows

Qt for Windows Runtime Technology Preview Released

Published Thursday December 12th, 2013 | by

Today, we released the first iteration of our development efforts of porting Qt to Windows Runtime.

As a reminder, this includes multiple targets. First of all, you will be able to create Windows Store Apps for Windows 8 and subsequent versions. Also Windows RT, the operating system by Microsoft for tablets is supported. Lastly, Windows Phone 8 will also be supported, as it shares a significant amount of APIs with WinRT.

So far we have been aiming to get the basics right:

  • Configure Qt to find compilers for the different mkspecs we created
  • Automatically setup the cross compile environment without any manual tweaking. Some of you might remember “setcepaths” from the Windows CE port. Things like this are not required, configure and qmake will do all that magic for you
  • Compilation and support for most parts of qtbase

The last item also implies that Qt Quick 2 is not supported with this initial preview. But in case you want to test your widget-based application, you should be able to do so. It is important to note that the WinRT Technology Preview is based on the dev branch of Qt’s next minor release and not on today’s version, Qt 5.2.

To get started all you need to do is download the source package and call:

configure -xplatform winrt-x86-msvc2013

Followed by “nmake/jom” for an x86 build for WinRT with Visual Studio 2013. Other combinations are x64, msvc2012 and winphone for Windows Phone.

After compilation, you can then use this to build your project. Creating an app bundle and installation of this is documented here. As a pre-warning, manual steps are required which we will fix for the final version.

So what is coming next?

First, we want to improve the quality of existing modules and also ease the development workflow up to a level which you are used to for other platforms. Afterwards, the modules for supporting Qt Quick 2 will be added, broadening from there over the other Qt Essential and Qt AddOns modules. The aim is to provide frequent updates to you so you can evaluate the quality of the port.

But for now, we need your help and feedback. Please download the package from the Digia Qt Customer Portal or from for the open-source version and report any issues you will find. And of course, if you feel like you want to contribute to this project, you are more than welcomed.



Posted in Qt, Releases, Windows

Visual Studio Add-In 1.2.2 Released

Published Wednesday July 3rd, 2013 | by

Visual Studio Add-In is updated for Qt 5.1 in version 1.2.2. It provides updated documentation of Qt 5.1 and two bug fixes.

Compared to previous Visual Studio Add-In version the full list of changes in version 1.2.2 is:

  • Qt 5.1 help documents included
  • Incorrect overwriting of the environment setting value on every build/run removed. (QTVSADDINBUG-159)
  • Links in Qt help not working, fixed. (QTVSADDINBUG-160)

Similarly as before the Visual studio Add-In is available for both Qt Enterprise and open-source users with the Qt Enterprise version providing additional functionality needed for Qt Quick 2, more details here.

If you hold a valid Qt Enterprise license, you can download the new Visual Studio Add-In from the Customer Portal. The open-source version can be downloaded from the Qt Project. If you are not a Qt Enterprise licensee, but want to try out the additional functionality, you can try it with our free 30-day evaluation.


Posted in Windows

Introduction to Windows RT Frameworks

Published Friday June 14th, 2013 | by

It happens seldomly, but a couple of weeks ago I had the chance to look at some parts of the Windows Runtime port again and now I have some time to write about the outcome.

One of the tedious items when working on the port is that all applications have to be “pre-packaged” to be run on the host system. As this is not really a cross-compile environment, where you need to deploy an application and its dependencies to a device, it feels weird. On the other hand it reflects the real world scenario pretty well, which helps you as an app developer so that you do not forget to put items into the final package.
So right now the test build needs to look like this:

  • App.exe
  • AppManifest.XML
  • QtCore5d.dll
  • Platform/Imageformat plugins…

That implies that you need to copy Qt every time you want to test something. This usually is not a problem for an application developer, who copies Qt once. Doing that while developing on Qt itself is time consuming and error-prone, as for each test application you need to copy again.
Browsing through the documentation I found the following option to be interesting: “Framework

Read more…


Posted in desktop, Qt, Windows | Tags: , , , , ,

Qt’s WinRT port and its C++/CX usage

Published Friday April 19th, 2013 | by


After Friedemann has given an initial introduction about Qt’s Windows Runtime port, I would like to give some further insight about technical aspects and our ways of working on the port.

When reading about Windows Runtime development (Windows 8 store applications and Windows runtime components) in connection with C++ you will find C++/CX again and again. Windows C++/CX are C++ language extensions which were developed by Microsoft to make software development for Windows Runtime easier by bringing it “as close as possible to modern C++” (Visual C++ Language Reference (C++/CX)). In some cases, these extensions look similar to C++/CLI constructs, but they might have other meanings or slightly different grammar.

The first thing that catches someone’s eye when one has a look at C++/CX documentation or an example/application are lines like
Foo ^foo = ref new Foo();
The ^ is basically a pointer, but gives the additional information that it is used on a ref-counted COM object so that memory management happens “automagically”. The “ref new” keyword means that the user wants to create a new “Ref class” (see Ref classes and structs in Type System (C++/CX)), which means that it is copied by reference and memory management happens by reference count.  So there isn’t much magic involved in that line; it only tells the compiler that the object’s memory can be managed by reference count and the user does not have to delete it himself.

Basically C++/CX is just what its name tells us it is – extensions to the C++ language. Everything ends up as native unmanaged code quite similar to the way Qt works. Some people might argue whether it is necessary to reinvent the wheel for the n-th time where a lot of the “problems” are actually solved in C++11 (by the way, auto foo also works in the example above), but that is what was decided for Windows Runtime development.

Use of C++/CX inside Qt’s WinRT port

Microsoft has said on different occasions (among others during the Build conference 2012) that everything that can be done using C++/CX can also be done without the extensions, as everything ends up as native code in either case. So we had to decide whether we want to use the new fancy stuff or take the cumbersome road of manual memory management etc. Theoretically there is nothing that keeps us from using C++/CX in Qt’s WinRT port, but there are some reasons why we try to avoid them.

For one, these extensions might prevent developers who are willing to help with the Windows Runtime port from having a deeper look at the code. If you do not have any previous experience with this development environment, having new constructs and keywords (in addition to new code) might be enough for you to close the editor right away. While WinRT code which doesn’t use CX might not be especially beautiful, there are no non-default things which might obscure it even more.

Another issue is that Qt Creator’s code model cannot handle these extensions (yet). You don’t get any auto completion for ^-pointers, for example. This can of course be fixed in Qt Creator and time will tell whether it will be, but at the moment the port and basic Qt Creator integration (building, debugging & deployment) are our first priorities.
Due to these facts, we decided that we do not want to use the extensions. Though, if someone wants to help out with the port and is eager to use CX he/she might be able to persuade us to get the code in (after proper review of course ;) ).

Problems and challenges of not using C++/CX

The main problem when it comes to development of Windows Runtime code without using C++/CX is the severe lack of documentation. While the MSDN documentation generally can be improved in certain areas, it almost completely lacks anything about this topic. But thanks to Andrew Knight, who gave me an initial overview how things are to be used and was always helpful whenever I had additional questions, I think I am getting the grip on things. In order to help others who want to join the efforts (and have all the things written down), I will cover some basic areas below.


The namespaces given in the documentation are always the same for the CX usage of the classes,  just with “ABI” added as the root namespace. So for StreamSocket, Windows::Networking::Sockets becomes ABI::Windows::Networking::Sockets. Additionally, you probably need Microsoft::WRL (and also Microsoft::WRL::Wrappers). WRL stands for “Windows Runtime C++ Template Library” and is used for direct COM access in Windows Runtime applications – but you will also need its functionality when omitting CX (for creating instances for example).

Creating instances

When not using CX, most of the classes cannot be accessed directly. Instead, there are interface classes which need to be used. These interfaces are marked by an ‘I’ in front of the class name so that StreamSocket becomes IStreamSocket. As these interfaces are abstract classes, they cannot be instantiated directly. First of all, you have to create a string which represents the class’s classId.
HStringReference classId(RuntimeClass_Windows_Networking_Sockets_StreamSockets);

These RuntimeClass_Windows… constructs are defined in the related header files and expand to strings like “Windows.Networking.Sockets.StreamSocket” for example. The way objects can be instantiated depends on whether the class is default constructable or not. If it is, ActivateInstance can be used to obtain an object of the type you are after.

IStreamSocket *streamSocket = 0;
if (FAILED(ActivateInstance(classId.Get(), &streamSocket)) {
// handle error

Unfortunately, the ActivateInstance convenience function fails for StreamSocket in that case as it expects a ComPtr as parameter. In order to avoid that failure one has to take the long way using RoActivateInstance

IInspectable *inspectable = 0;
if (FAILED(RoActivateInstance(classId.Get(), &inspectable)) {
// handle error
if (FAILED(inspectable->QueryInterface(IID_PPV_ARGS(&streamSocket)))) {
// handle error

If the class is not default constructable, it has to use a factory in order to create instances. These factories can be obtained by calling GetActivationFactory with the appropriate class Id. One example of a class like that would be HostName:

IHostNameFactory *hostnameFactory;
HStringReference classId(RuntimeClass_Windows_Networking_HostName);
if (FAILED(GetActivationFactory(classId.Get(), &hostnameFactory))) {
// handle error
IHostName *host;
HStringReference hostNameRef(L"");
hostnameFactory->CreateHostName(hostNameRef.Get(), &host);

People who are used to Windows development probably have already noticed that all this is COM based. That means that all this has been around for ages and is loved everywhere.

Calling static functions

For classes which have static functions there is an extra interface for these functions. These interfaces are marked by “Statics” at the end of the “basic” interface name and can also be obtained by using GetActivationFactory. One example would be IDatagramSocketStatics which contains GetEndpointPairsAsync for example.

IDatagramSocketStatics *datagramSocketStatics;
GetActivationFactory(HString::MakeReference(RuntimeClass_Windows_Networking_Sockets_DatagramSocket).Get(), &datagramSocketStatics);

IAsyncOperation<IVectorView *> *endpointpairoperation;
HSTRING service;
WindowsCreateString(L"0", 1, &service);
datagramSocketStatics->GetEndpointPairsAsync(host, service, &endpointpairoperation);

The endpointpairoperation defines the callback(s) for this asynchronous function, but that topic could be covered in another post. The interesting parts here are how the datagramSocketStatics pointer is filled by calling GetActivationFactory and the actual call to the static function by datagramSocketStatics->GetEndpointPairsAsync(...).


There is a way to use reference counted memory management even without using CX. It can be achieved by using the Microsoft-provided smart pointer ComPtr. So
IStreamSocket *streamSocket
would become
ComPtr<IStreamSocket> streamSocket.
When using these, we had some memory access errors we could not explain (but did not investigate much further). In addition to that, Qt Creator does not support code completion with “streamSocket->” but one would have to call “streamSocket.Get()->”. Thus we decided not to use ComPtr but keep using “normal” pointers. All you have to do is to remember to call “Release” as soon as you are done with the pointer.

All in all, we try to avoid these extensions even though it might not make the code beautiful. If you want to contribute though and feel at home using these, feel free to create a patch containing CX code. If you have any further questions or advice, feel free to add them in the comments or join us in #qt-winrt on freenode.


Posted in Background, Qt, Windows

Visual Studio Add-In 1.2.1 for Qt 5 Released

Published Thursday April 11th, 2013 | by

It has been a busy week – today we are releasing Visual Studio Add-in 1.2.1 for Qt 5. This is mainly a bug fix release targeting problems found in previous releases. In addition to bug fixes the Add-In now supports Visual Studio 2012 debugger visualizers for Qt 5 classes. On the commercial version there is also support for Qt Quick.

As before, at least Visual Studio Professional is required to use the Add-in. Supported versions are Visual Studio 2012 (update 2 recommended), 2010 and 2008.

Highlights of Visual Studio Add-In 1.2.1 include:

  • Qt Quick project wizard, QML keyword highlighting and QML file preview in the commercial version
  • Visual Studio 2012 debugger visualizers for Qt 5 classes
  • Possibility to use Qt 4 Add-in and Qt 5 Add-in in same computer (in turns)
  • Incorrect Qt 5 library/module names and include paths fixed

You can find the detailed list of changes to the Visual Studio Add-in 1.2.1 in the change log.

Using Qt 5 VS Add-in and Qt 4 VS Add-in together

Qt 4 Visual Studio Add-in is not allowed to run at same time with the Qt 5 Add-in, if found it will be closed. It is however possible to use both Qt 4 and Qt 5 Add-ins in turns. The user must choose Qt-version within the Add-in manager (both can not be active simultaneously). Extra care must be taken to use correct project and class wizards because both Qt 4 and Qt 5 ones are visible if both Add-ins are installed in system.

Qt Quick support in the commercial version

Digia has created additional functionality to the Visual Studio Add-In available only for the commercial licensees of Qt. The commercial version has new Qt Quick2 Application project wizard for creating project that can contain both QML and C++ code. The commercial Add-In also provides keyword highlighting for QML files and new preview feature for launching qmlviewer.

Get it from the Customer Portal of Qt Project Downloads

The new Visual Studio Add-In 1.2.1 is available for both commercial and open-source users. If you hold a valid commercial license, you can download the new Visual Studio Add-In from the Customer Portal. The open-source version can be downloaded from the Qt Project. If you are not a commercial licensee, but want to try out the additional functionality, you can try our the commercial version with our free 30-day evaluation.

I hope you enjoy developing Qt 5 applications with Visual Studio. Please provide us feedback either through the commercial support or via the Qt Project mailing lists.


Posted in Windows

Port to Windows Runtime kick-started

Published Friday February 15th, 2013 | by

With Windows 8, Microsoft introduced a new platform, the Windows Runtime. On the desktop, the operating system provides 2 modes:

Classic mode: This mode shows the familiar Windows desktop known from Windows 7 (with the exception of the start menu), in which traditional applications using the Win32 API run. No modifications are required for Qt 4 or Qt 5-based applications to run in this mode.

Modern UI (formerly known as Metro mode): This is a new type of user interface intended for tablet and phone UIs on which Windows Store Apps run. These applications use a new API called  Windows Runtime, which is based on the Component Object Model (COM). A similar API exists on Windows Phone 8.

Research work on how to port Qt 5 to use Windows Runtime was started by Andrew Knight from Digia and is visible in the winrt branch of the qtbase repository. Recently, further contributions by Kamil Trzciński were added to it (check out his blog). Now, with Qt 5.0 out of the door, we would like to kick off this platform port. This completes our cross-platform offering in addition to the ports for the widely used Android and iOS platforms.

We plan to continue development in this branch, aiming for as complete as possible port. Technical details can be found at here.

The first milestone is to get simple raster windows to be drawn on the screen. Later, we will investigate porting ANGLE to get OpenGL ES 2.0 support required for QML2.

Similar to the android branch, the idea is not to merge the branch, but later look at it and apply its changes to the dev branch.

To play with the branch, create an environment with a x86 MSVC2012 compiler and configure Qt with:

configure -nomake examples -nomake tests -developer-build -opensource -confirm-license -xplatform winrt-x86-msvc2012

We are also planning on creating a Qt Creator plugin to support deployment. Andrew Knight has already started on it in the winrt branch of his Qt Creator repository.

The work has still the “Research” status, so, we are not able to give any release dates yet. We aim to have something ready for the 5.2 release. However, since the development happens in the public winrt branch, the current state is always visible and it is easy to participate.

Contributions and help are warmly welcome.

Happy Hacking!


Posted in News, Qt, Windows

Visual Studio Add-In 1.2.0 for Qt 5 Released

Published Wednesday December 19th, 2012 | by

This week we released Qt 5.0 with Qt Creator integrated into the package. Today I have good news for those who prefer to use Visual Studio. We have now released new Visual Studio Add-In 1.2.0 for Qt 5. In addition to supporting Qt 5 it provides some additional goodies such as support to Visual Studio 2012.

The new Visual Studio Add-In 1.2.0 supports Visual Studio 2012, 2010 and 2008 for developing Qt 5 applications. It understands the new modularized structure of Qt 5, and includes the new documentation. Functionality and requirements are otherwise similar as with the previous Add-In, so you will need at least Visual Studio Professional to use it.

Highlights of Visual Studio Add-In 1.2.0 include:

  • Project creation wizards updated to follow Qt 5 module structure
  • Project settings form updated to follow Qt 5 module structure
  • Help documents updated to Qt 5.0
  • Support for Visual Studio 2012, 2010 and 2008
  • Parameter passing to lupdate fixed (QTVSADDINBUG-131)

You can find the detailed list of changes to the Visual Studio Add-In 1.2.0 here.

One thing to note is that there is no Qt 4 project creation wizards and project settings in the Qt 5 Visual Studio Add-In, and unfortunately it is currently not possible to use both the Qt 4 and Qt 5 Visual Studio Add-Ins simultaneously. We plan to release an updated version of the Qt 4 Add-In during Q1/13 to address this issue.

The new Visual Studio Add-In 1.2.0 is available for both commercial and open-source users. If you hold a valid commercial license, you can download the new Visual Studio Add-In from the Customer Portal. The open-source version can be downloaded from the Qt Project.

I hope you enjoy developing Qt 5 applications with Visual Studio. Please provide us with feedback either through the commercial support or via the Qt Project mailing lists.

PS. I changed the release date visible in the blog so that Qt 5.0.0 stays at the top. The real date of this release is 21st December 2012.



Posted in Announcements, Compilers, desktop, Qt, Windows | Tags:

Graphics on Windows from a different angle

Published Wednesday October 24th, 2012 | by

With Qt 5 we are making the bold move of making OpenGL 2.0 a requirement for using  QtQuick2. There are several challenges with this new requirement, many of which have been discussed on the blogs and mailing lists already, but today I want to talk about one issue in particular and that’s OpenGL on Windows.

Microsoft has included OpenGL in Windows since Windows 98 (or earlier?), however the initial version was a software implementation and only supported version 1.1 of the API. Over time, the implementation has been improved so that today it is implemented as a wrapper on top of Direct3D. This is great, but unfortunately the version of the API that is supported has remained the same and that means it is not sufficient for running QtQuick2 or even Qt’s GL paint engine. You can insert your own conspiracy theory about why Microsoft has let OpenGL stagnate on Windows, but every theory will likely involve Direct3D. D3D is a component of DirectX that offers similar functionality to OpenGL. It is most commonly used by game developers to target desktop Windows and also XBox, but is also used by CAD applications.

Typically when a developer wants to run or develop something that requires OpenGL on Windows, the first place they go is to their hardware vendor’s website and download the latest drivers from Intel, NVidia, AMD or whoever.. This is fine, but can be somewhat inconvenient for end users of OpenGL applications. We wanted to avoid this problem with Qt applications so deployment would essentially be the same as with Qt 4 (but with possibly more DLLs). Luckily for us, we weren’t the first people to experience this problem. Most browsers these days (except IE) are supporting WebGL out of the box. WebGL is a 3D canvas API available through Javascript. The API is based on OpenGL ES 2.0 and the shader language is GLSL ES. So how can browsers offer an OpenGL 2 API without requiring new drivers? The solution is called the ANGLE (Almost Native Graphics Layer Engine) project.

ANGLE is a BSD licensed project that implements the OpenGL ES 2.0 API on top of DirectX 9.0c. In addition to this, it also implements the EGL API and contains a shader cross compiler that takes GLSL ES code and converts it to HLSL which is the shader language used in DirectX. So ANGLE allows us to essentially run the Qt Scene Graph on top of DirectX without modifying any of our code. Friedemann has already done most of the hard work by adding support for GLES2 and EGL into the Windows platform plugin and as a result it has been possible to use Qt 5 with ANGLE for quite some time now. However, to make this experience more painless, we are including ANGLE in Qt’s 3rdparty directory and making it the default OpenGL configuration on Windows.

For QML applications and lightweight OpenGL apps, you can use this new configuration to deploy your apps without requiring your end users to install new graphics drivers. On the other hand if your application requires full desktop OpenGL, then it’s simply a matter of configuring Qt with “-opengl desktop” and you get the same behavior as before.

One additional benefit of using ANGLE on Windows is that our graphics pipeline and multimedia pipeline are now based on the same underlying technology (DirectX) so we can take some shortcuts to get video frames into the Scene Graph more efficiently. Taking this one step further, Windows Vista introduced a new driver model called WDDM and one of the features here is that DirectX surfaces can now be shared across processes. This little feature will come in handy for our WebKit2 work which has seperate processes for the web renderer and the ui. All of this goodness might not make it into the 5.0 release, but it’s  all in progress so hopefully it makes an appearance soon!


Posted in Graphics, OpenGL, Qt, Windows

  1. Pages:
  2. 1
  3. 2
  4. 3