Qt 5.6 doesn't compatible with Windows XP

flyingtree

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?

hskoglund

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..

flyingtree

@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

flyingtree

@hskoglund
I downloaded qt precompiled binaries package at "http://download.qt.io/development_releases/qt/5.6/5.6.0-beta/" and it has the same problem.

hskoglund

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

flyingtree

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

hskoglund

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?

kuzulis

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

https://wiki.qt.io/Qt-5.6.0-tools-and-versions

hskoglund

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.

hskoglund

@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

flyingtree

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

flyingtree

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