Building an application for Windows XP SP2
-
With VS redistributable packages you don't have to provide the installer. You can bundle dlls from that package directly with your app. Just find the appropriate msvcp*.dll / msvcr*.dll in your VS2015 redist directory and copy them over.
Btw. I hope those accounting and hr computers are at least not connected to the internet. SP2 is a 13 year old patch to a 17 year old OS that has no producent support even for security vulnerabilities. If these computers deal with people's data and money I wouldn't put them anywhere near a network cable or you're just asking for trouble.
-
I have the same problem. I need to make sure the programs work on WinXP as I find many places still have this software. Upgrades to the OS are not an option.
My solution is Qt 5.6.0 compiled from source on a virtual machine running WinXP SP2. I use MinGW instead of visual studio. The key options when compiling Qt are the configure options '-target xp' and '-no-directwrite'.
I suspect Qt 5.6.3 will work in this setup (I haven't upgraded yet because of the amount of work and lack of problems with 5.6.0). I don't know if Visual Studio 2013 will complain about WinXP SP2 but if it requires SP3 to even install then you might have to go with MinGW instead. Maybe an older version of Visual Studio? I prefer MinGW because it doesn't have the problems with missing redistributables when you try to run your program on different machines. Installing anything on a target computer is not an option (particularly something old like WinXP where you don't know what will happen as a result) so Visual Studio is something I avoid using.
I did have to change the configure executable for Qt so that it would run on WinXP in order to build Qt on WinXP. This executable has the minimum version set for a newer version of Windows but a simple edit can fix this. There is some information about this here: http://www.tripleboot.org/?p=423
The downside of all this is that I haven't moved forward with the version of Qt that I am using. In the past I would always have the latest and greatest and as time goes on it gets more and more annoying. I don't know your situation but you could specify a minimum OS for your software and just move forward. It is more and more common to find programs that no longer run on WinXP. I really wish WinXP would simply go away...
-
@Rondog said
I really wish WinXP would simply go away...
Stop supporting it then :)
I know in some part of the world XP is still really common and its
all about money. SO i do understand why you want/need to run on it.And i dont think it will die soon
https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0it has bigger share than macOS and linux.
-
Hi, if you really need to support WinXP SP2 I think your only option is to go with a patched msvcr120.dll (which you need to copy/distribute together with your .exe file). Turns out such a beast is pretty easy to find, for example here If you scroll down to the end you'll find a link to a patched msvcr120.dll that I think works on XP SP2 (I only have tested it on XP SP3).
To make sure it's not a virus, I diff'ed it to the kosher msvcr120.dll and it's only about 50 bytes that differ (both .dlls have the same size).
P.S. How the patch works: it replaces the call to GetLogicalProcessorInformation() with a call to GetExitCodeThread() (which is allowed on XP SP2). If you look at the API docs you'll see that calling GetExitCodeThread with the same stack setup as for GetLogicalProcessorInformation is harmless and doesn't crash the program. However, this requires that msvcr120.dll (or some part of Qt) does not really need the information that GetLogicalProcessorInformation returns :-)
Edit: forgot to mention, I think getting MS Visual C++ 2015 Redistributable to work on XP SP2 is much harder than getting MSVC 2013 to work. So you best bet is that patched msvcr120.dll...
-
Thank you for the replies.
@mrjj
Out of curiosity I've tried the tool they provide in the description to the video, and for some reason it refuses to patch kernel32.dll on my virtual machine running XP SP2. That is, of course, leaving aside the fact that patching an end user's system is undesirable.With VS redistributable packages you don't have to provide the installer. You can bundle dlls from that package directly with your app. Just find the appropriate msvcp*.dll / msvcr*.dll in your VS2015 redist directory and copy them over.
I thought so as well, but it proved to be not so simple.
If I build the application with MSVC 2015 kit, it reasonably requires msvcp140.dll and vcruntime140.dll to be placed in its directory. Once the files are there, the program then wants to see api-ms-win-crt-runtime-l1-1-0.dll, which is nowhere to be found in Qt or Visual Studio directories. As it turned out, api-ms-win-crt-runtime-l1-1-0.dll resides in two subdirectories of %WINDIR%/winsxs (probably came with Visual C++ 2015 Redistributable Package itself). After I put a copy in the program folder, subsequent runs greet me with the following error: "The procedure entry point ucrtbase.terminate could not be located in the dynamic link library api-ms-win-crt-runtime-l1-1-0.dll". This happens both on XP SP2 and XP SP3.
Installing MS Windows Installer 4.5 and MS Visual C++ 2015 Redistributable fixes the error (at least on XP SP2). So I switched to MSVC 2013 in hopes to avoid this problem.
Btw. I hope those accounting and hr computers are at least not connected to the internet. SP2 is a 13 year old patch to a 17 year old OS that has no producent support even for security vulnerabilities. If these computers deal with people's data and money I wouldn't put them anywhere near a network cable or you're just asking for trouble.
They are connected to the Internet. I myself would like to refrain from giving a judgement in this particular case. I'll just say that it is how things are still being done in some parts of the world.
My solution is Qt 5.6.0 compiled from source on a virtual machine running WinXP SP2. I use MinGW instead of visual studio. The key options when compiling Qt are the configure options '-target xp' and '-no-directwrite'.
Compiling Qt from source to suit specific needs is definitely an interesting approach. Unfortunately, right now I have zero experience in doing that, and the manuals I've read before seem to be quite daunting. I guess there is no other way but to try and study it again in the near future, but before that there's still MSVC 2010 and possibly 2008 to test.
I have tried compiling my application with MinGW, but it does not seem to understand the following lines when I put them in .pro file:
win32 { contains(QMAKE_TARGET.arch, x86_64) { QMAKE_LFLAGS_WINDOWS = /SUBSYSTEM:WINDOWS,5.02 QMAKE_LFLAGS_CONSOLE = /SUBSYSTEM:CONSOLE,5.02 } else { QMAKE_LFLAGS_WINDOWS = /SUBSYSTEM:WINDOWS,5.01 QMAKE_LFLAGS_CONSOLE = /SUBSYSTEM:CONSOLE,5.01 } }I think it’s safe to say that I have no idea how to deal with MinGW.
@hskoglund
Works like a charm! Surely, third party edit is a bit fishy, but it can’t be helped under these circumstances.I don’t think my application makes any use of GetLogicalProcessorInformation() at all, so this will be the solution for now. Wish I was skilled enough to make such an edit myself from a clean .dll file, but I guess this goes beyond the scope of Qt forum. Still, worth looking for a guide or at least some tiny hints.
-
@bapx About setting QMAKE_LFLAGS_WINDOWS for MinGW: that flag is MSVC-specific and as you mention is not understood by MinGW. Also it is not needed by MinGW, since it does that setting automatically by itself to /SUBSYSTEM:WINDOWS,4.0 so that (in theory) the resulting .exe file also works on Windows NT 4.0 and Windows 2000.
And a hint for patching a clean msvcr120.dll so that it works for XP SP2: you start by editing the IAT part of the .dll so that the function call is changed (without the rest of the .dll having a clue :-)
here is a tutorial -
@mrjj said in Building an application for Windows XP SP2:
@Rondog said
I really wish WinXP would simply go away...
Stop supporting it then :)
I know in some part of the world XP is still really common and its
all about money. SO i do understand why you want/need to run on it.And i dont think it will die soon
https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0it has bigger share than macOS and linux.
It is not a case of supporting XP. I have various tools and utilities that I wrote to help me do my job. Some customers still run XP and I need to be able to run on this OS when I move from company to company. Using a replacement PC (laptop) for these older system is a work around but that creates many more problems. It would be different story if I had a software product but I have more of a service and I need my stuff to work on this OS.
@bapx If you want to compile your Qt program with MinGW you need to have a version of Qt compiled with MinGW. I got the impression you tried to use MinGW to compile your Qt program but your version of Qt is for Visual Studio.
It is not that hard to compile Qt. You download the sources, extract them somewhere, remove (delete) the modules from the source tree you don't need (webkit for example), then run configure from the qtbase folder.
This is my configure line followed by make to build Qt. I don't know what you need (or don't need) so you should check out the options first (run configure -help to get a list of options).
configure -no-icu -nomake examples -nomake tests -opengl desktop -plugin-sql-mysql -target xp -no-directwrite makeYou will need to modify the configure executable to work on WinXP for your version of Qt.
You can download a precompiled version of Qt that includes the MinGW compiler if you are not comfortable setting this up. The version I use is 4.8.2 which I probably got from an earlier version of Qt than 5.6.x. Qt 5.6.x should use MinGW 4.9.1 according to the Qt wiki.
If you happen to find a better solution to this problem please post it. I mean if patching a couple of DLL's and some specific options in Visual Studio set and everything works like a champ then this would be something to consider. I stopped using Visual Studio back around 2003 (?) and haven't been interested in using this at all due to the redistributable headaches I often see with programs from other people.
-
@bapx If you want to compile your Qt program with MinGW you need to have a version of Qt compiled with MinGW. I got the impression you tried to use MinGW to compile your Qt program but your version of Qt is for Visual Studio.
No-no, initially I tried to build it with Qt 5.7.1 for MinGW 5.3.0, but was not successful: the linker needed some .dll to finish the job, and it couldn't be found anywhere. This failure prompted me to try MSVC.
Back then I did not know that, as people say, 5.7.1 is not recommended for applications running under XP, so that's where the mistake was.
A day ago I've reinstalled Qt 5.6.3 bundled with MinGW 4.9.2 and removed the aforementioned MSVC-specific code lines from the .pro file (although kept DEFINES += _ATL_XP_TARGETING in: maybe it is also not necessary, but it doesn't seem to be harmful either). Compiling went smooth save for a few minor warnings, and the resulting program works well both on XP SP2 and XP SP3. Turns out, there was another way all along aside from patching msvcr120.dll!
Now I wonder if there's even a need to go through old versions of MSVC, but I feel like compiling Qt from source is something I'd like to do one day just for the experience, so your suggestions are helpful, thank you.
@bapx About setting QMAKE_LFLAGS_WINDOWS for MinGW: that flag is MSVC-specific and as you mention is not understood by MinGW. Also it is not needed by MinGW, since it does that setting automatically by itself to /SUBSYSTEM:WINDOWS,4.0 so that (in theory) the resulting .exe file also works on Windows NT 4.0 and Windows 2000.
I had my suspicions about those lines being used only for MSVC, thanks for the confirmation.
I've tested my program after building it with MinGW, and no luck on Windows 2000, but it's not important at all. Support for XP SP2 is what I'm after.
And a hint for patching a clean msvcr120.dll so that it works for XP SP2: you start by editing the IAT part of the .dll so that the function call is changed (without the rest of the .dll having a clue :-)
here is a tutorialAn intriguing read, although for now my .dll files always come out botched. While understanding that I need considerably more knowlegde and practice, I thnk I was able to learn a thing or two.
-
Hello
In fact I "accidentaly" got hold on a fixed and official Kernel32.dll from Microsoft, which exports the GetLogicalProcessorInformation function you need.
The method used by WantSkaipBack, as show in the youtube video, is bad imho, because it simply replaces Kernel32.dll by a SP3 (russian) one !
Append /b:SP2QFE to the installer to force the QFE version of the hotfix (as the GDR default version does NOT feature GetLogicalProcessorInformation). I guess this last Kernel32.dll hotfix was compiled "pre-SP3".
It just works!
