Important: Please read the Qt Code of Conduct -

Qt 5.6 doesn't compatible with Windows XP

  • Windows API GetUserDefaultLocaleName is used in qwindows.dll, but it is not supported under Windows XP.
    I reported a bug in QT Bug Tracker QTBUG-50188.

    Has anyone met the same problem?

  • Hi, if you look in the code for qwindows.dll it seems that GetUserDefaultLocaleName is used in the QWindowsFontEngineDirectWrite class, and that font engine should only be selected for Vista and Windows 7. So it seems harmless..

  • @hskoglund
    Yes, I found it in the QWindowsFontEngineDirectWrite class, but I build qt 5.6 with configuration -target xp, so why this interface is referenced in qwindows.dll?

    My configurations configure -debug-and-release -opensource -confirm-license -mp -icu -openssl -nomake examples -nomake tests -target xp -skip qtwebkit

  • @hskoglund
    I downloaded qt precompiled binaries package at "" and it has the same problem.

  • I also downloaded and installed the 5.6 beta and you are correct, indeed it's a bug, in Windows XP you cannot start Qt Creator or start a program compiled with Qt Creator.

    While waiting for this bug to go away, you can get around it quite easy by patching the IAT for kernel32.dll in qwindows.dll and qwindowsd.dll. Note that also the qwindows.dll that Qt Creator uses needs to be patched.

    I opened a hex editor and searched for GetUserDefaultLocaleName, then I changed it to GetLastError. Also note that you need to change the hex address preceding GetUserDefaultLocaleName to the one that GetLastError has. Here is the diff for patching the qwindows.dll belonging to MinGW 4.92 in the 5.6 beta:
    (the original qwindows.dll is in the left column, the patched one is the right column)

    2015-12-29 17:16:06,33 C:\Qt\5.6\mingw492_32\plugins\platforms fc/b C:\temp\qwin
    dows.dll *
    Comparing files C:\TEMP\qwindows.dll and qwindows.dll
    001519DA: A0 03
    001519DF: 55 4C
    001519E0: 73 61
    001519E1: 65 73
    001519E2: 72 74
    001519E3: 44 45
    001519E4: 65 72
    001519E5: 66 72
    001519E6: 61 6F
    001519E7: 75 72
    001519E8: 6C 00
    001519E9: 74 00
    001519EA: 4C 00
    001519EB: 6F 00
    001519EC: 63 00
    001519ED: 61 00
    001519EE: 6C 00
    001519EF: 65 00
    001519F0: 4E 00
    001519F1: 61 00
    001519F2: 6D 00
    001519F3: 65 00

  • @hskoglund
    Sounds great! But I am not familiar with IAT patch. : )

  • Hi, "IAT patch": IAT stands for Import Address Table and because GetUserDefaultLocaleName it's in there in qwindows.dll's IAT, that's why Qt Creator in the 5.6 Beta cannot start in Windows XP.

    And if you get rid of that entry in the table in qwindows.dll then everything will be happy in Windows XP. So my patch just tells WIndows, when loading qwindows.dll, that don't look for "GetUserDefaultLocaleName" in C:\Windows\System32\kernel32.dll, instead look for "GetLastError" :-)

    If you want, I can post here the patched .dlls needed, for you it's MSVC2013?

  • Qt Champions 2020

    As far I know, Qt 5.6 does not support Windows XP anymore

  • Yes that 5.6 wiki does not show XP anymore, you're correct.

    In reality though (with this beta anyway), once you've patched away the dependency of GetUserDefaultLocaleName in qwindows.dll, Qt Creator runs better than ever on my XP machine; both in 5.5 and 5.5.1 I had to disable the Welcome plugin for Qt Creator to start. And in 5.5.1, you got that annoying messagebox saying "...strnlen.. something wrong" in msvcrt.dll, about 10 times when you launched Qt Creator. But in this 5.6 beta I can yet again (as in 5.4) enjoy the examples gallery :-)

    Yes Windows XP is getting long in the tooth but I've got some customers still running Windows 2k3 servers (from Qt's point of view that's equivalent XP) and I'm grateful still to be able to use Qt on them.

  • @flyingtree if you try build Qt again, but this time with DirectWrite disabled (as in 5.5) then you should be fine in Windows XP:
    configure -debug-and-release -opensource -confirm-license -mp -icu -openssl -nomake examples -nomake tests -target xp -skip qtwebkit -no-directwrite

  • @hskoglund
    Ok, I am going to try it today.

  • @hskoglund
    Yes, -no-directwrite is the answer! Thank you very much!

Log in to reply