I'm stuck in a deployment issue with my Qt 5.4.0 application.
After two days of research, my app really doesn't want to execute on Windows XP !
I have created my deployment folder with windeployqt provided by my Qt installation. When I double-click on *.exe, I have always :
The procedure entry point vsprintf_s could not be located in the dynamic link library msvcrt.dll.
Dependency walker hasn't really helped me and I don't know what I can try now.
Note :
SDK : Qt 5.4.0 (MSVC 2010, 32 Bits)
IDE : QT Creator 3.3.0
Compiler : MinGW 4.9.1 32 Bits
Need to run on : Windows XP Pro SP2 32 Bits
App works like a charm on Windows 7 with same configuration (IDE, compiler, etc.)
While Guilhem G. is correct in the broader sense, it doesn't mean you actually called that function yourself (speaking now to a theoretically other person running into this issue like me, heh). I believe it's a bug with MinGW's XP support; I've seen bug reports of similar issues, including nearly the exact same issue in a much earlier version of Qt that was then fixed. I haven't seen this particular incarnation, which I actually ran into myself. I suppose I should probably submit a bug report!
Anyways, I've fixed it without changing any of the code I've written myself. What I had to do to fix it was twofold:
Switch over to using the msvc2010 compiler, since that set of C++ libraries rather unsurprisingly runs fine on Windows XP (AFAIK they still haven't dropped XP support with the latest version).
Switch over to Qt 5.5 (I'll explain why at the end).
For the compiler, you'll need then either Microsoft Visual Studio 2010 (hence the name), or the older Windows SDK that ships with it; the "Microsoft Windows Software Development Kit for Windows Server 2008 and .NET Framework 3.5" release should do the trick for you if you don't have a Visual Studio 2010 license.
Once one of those is installed, I'd encourage you to install Qt 5.5 as compiled by MSVC2010. You can either start a fresh installer or use the Qt Maintenance Tool which should already be installed.
Once that kit is installed, within your project (selecting "Projects" from the left-side menu) you should be able to go "Add Kit" and select Qt 5.5 msvc2010 32-bit, and if you now recompile and redeploy your application, it should run fine on XP.
Now, why did I insist on you upgrading to Qt 5.5? Well, there's some underlying issues with choosing a working OpenGL renderer on each version of Windows, and Qt 5.5 simplifies that a lot by having it fall back on OpenGL or ANGLE depending on what capabilities are actually detected, plus IIRC some other related fixes. So certainly if you're deploying a QML / Qt Quick 2.0 app across multiple Windows versions like I'm doing, it's worth upgrading to Qt 5.5.
The error was I called "sprintf_s" somewhere in my code (ok for recent windows on my dev machine but not for XP).
If you have the same problem when you search in your code don't use exactly the name of the function in the error message but an expression like *_s.
You probably call a secure API function somewhere !
Related
I tried running a QT C++ GUI sample in WinPE. It should just open an empty window.
It complains about missing d3d11.dll and dxgi.dll.
QT tries to use OpenGL, if there is no suitable driver, it uses DirectX with ANGLE. I tried removing the DirectX dependency by calling Qapplication::setAttribute(Qt::AA_UseSoftwareOpenGL) before the Qapplication instantiaton. No change, still requires those two dlls.
I tried to copy those two files from my regular Windows, and now the error is: “The procedure entry point CheckIsMSIXPackage could not be located in the dynamic link library dxgi.dll”
I don't need any HW acceleration, how could I make it run?
QT version: 5.14.2 (dynamic linking)
WinPE version: Windows 10 2004
Compiler: Visual Studio 2019 and Mingw 8.1 (I have tried both, same results)
Too late ? Not the solution but only an idea.
Actually I use Winpe WinPe 2009. When i install VirtualBox 6.1.16 in this winpe, i add opengl32.dll and other files. VirtualBox uses QT5 files. And i get the same error. With Depends.exe, i see that opengl32.dll needs this ChechIsMSIXPackage and loock for it in kernelBase.dll. But because kernelBase.dll which comes with winpe2009 doesn't contain this API, i take this kernelBase.dll from a normal W10 (in the ISO/Install.wim). And, in my case, virtualBox works well, QT5 also, opengl32 also.
Qt 5.12 does not depend on dxgi.dll but Qt 5.15 definitely seems to.
One option is to roll back your project to Qt 5.12, I can personally confirm that Qt 5.12 projects work great under Windows PE.
(This is assuming you are using the prebuilt Qt binaries from Maintenance Tool - otherwise there may be a config option to recompile Qt to avoid this).
It's late but since I just ran into this problem myself...
Apparently this dependency is introduced by the Rendering Hardware Interface, and what worked for me for WinPE 1809 was to build Qt 5.15 (.7 and .8) from source - in Msys2, by the way - after removing/commenting out the line include(rhi/rhi.pri) in qtbase/src/gui/gui.pro, and the configure command line includes -no-directwrite -no-opengl -no-icu.
In our project we switched from the Qt-Version 5.5.0 to 5.9.1
We are running Software, that runs partially on virtual machines with OpenGL 1.1 (standard I think). With Qt5.5 everything went fine and ANGLE mapped to DirectX correctly.
Since we are using Qt5.9.1, the OpenGL windows doesn't behave like they should, you can see the behaviour in the picture.
Difference Qt5.5 and Qt5.9.1
Is their a bug in the new Qt-version or am I missing something?
Would it change something if we build Qt5.9.1 again with configure -opengl dynamic?
P.S.: We changed from Visual Studio 2013 to 2015, but I don't think that this matters.
I had this problem as well and I solved it by compiling a newer version of angle and putting it right next to your exe. Can't run them correctly in QtCreator though (must deploy and then copy).
I have installed (and reinstalled) the QtSDK Community version on Windows 7 64-bit. When I launch Qt Creator there is no option for C++ Project. Others have solved this problem by making sure qmake.exe is properly detected under Tools-->Options-->Build & Run-->Qt Versions but it appears to be in my installation:
First go to File->New and check the drop-down box in the top right: Is it set to show the relevant templates ("All templates" is the save bet).
If it does: Please check the Kits tab in Tools>Options>Build & Run: Is there a kit using the desktop device type with a compiler and Qt version? Do compiler and Qt version match (same type and version)?
With the Qt in the screenshot you need to have MSVC 2013 set up and detected. MSVC 2010 or any other version does not work, nor does mingw since the binaries that result from building with one compiler and linking to a Qt built with a different compiler does tend to crash more or less randomly.
Once you have a Kit with a Qt version the additional wizards should become available.
I have a software which has to be deployed in Windows Xp and Windows 7 32 bit versions. Is it Ok to build the software in Win XP for for both platforms?
or
Should I build in Xp for deploying in Xp and build in Win7 for deploying in Win7?
The software is developed in C++
Both operating system will do the job. Just use the proper SDK version and deployment target constants (see targetver.h in C++ project template).
Yes you can build on any (modern) windows version for deployment on any other.
But you probably want to test on both!
If you really have to choose, use XP since Win7 is most likely XP-compatible.
I mean, there are more chances that your program will not run under XP if developped with Win7 than the opposite.
Of course, if you use the correct libs, it should be OK, but what if by mistake you use a Win7 only feature ?
More recent version are expected to be compatible with old versions, not the opposite.
I've built a C++ application using MSVC 2010, default compile settings (note: Using "Multithreaded" instead of "Multithreaded DLL" to avoid the Microsoft C++ runtime being needed).
I used only the STL and a few, old functions from the Win32 API (Windows.h).
Where will my app run? (98-7?)
Can the be any differences on how my app works on different PCs? As said: It's only a simple console app.
I'd be glad if you could add some additional information if you have it!
The Simplest answer is: Your app will run on Windows versions 5.0 and later - depending on what other APIs YOU use.
the hard limit of 5.0 is introduced in Visual C++ 2008 that stamps a 5 into the minimum OS version field in all the PE headers of all the executable files it produces.
As Windows NT is the only desktop OS with version's 5 and higher, this means that Windows 95, 98, ME cannot run programs made with VS 2008 and VS 2010. Windows 2000 is actually Windows NT 5.0, so it can be targetted. XP is 5.1, Vista 6.0, and in a twist of idiocy, Windows 7 is actually version 6.1 of Windows NT.
Take a look at "Using the Windows Headers" at MSDN. It describes how to configure the windows header files to support various mixtures of OS's.
I think you have to think about it the other way, what versions of Windows do you need to support, and then you can check if the APIs you need are supported or if you have to find workarounds.
After seeing Chris' comment about Win9x no longer being supported I took a look and discovered that the 2010 redist package only supports WinXP and upwards, so you might not be able to compile for Win 2000 either now?