Just noticed a File version (4.2.0.0) from a Qt application, when mouse goes over the file. However that seems to be the QtIF version, not my application version.
How to set that (mouser over) version of a Qt application (made by QtIF)?
This may be considered the expected behavior (f.ex. when used as an online installer), as the installer is able to install multiple versions of your program and/or upgrade your installation once a new version of your software becomes available. So, the installer is not directly related to a specific version of your software. See for example the Qt installer itself.
If you really want to control the version number, you should compile the installer from source and change the version string of the installer itself by slightly modifying the source code. In case you use the installer as a pure offline installer, this may indeed be appropriate.
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.
I am wanting to write unmanaged C++ code that reads from and writes to the event log. I am working with VS2017 and Windows 10. Everything I have read states that there is a utility ECManGen that is used to create the manifest file that is then run through the message compiler (mc). I have the latest Windows 10 SDK installed. According to what I have read, the executable is in the Bin directory under the SDK. I have scanned my entire drive and have not been able to find the utility. Has the utility been deprecated for something else? Is there somewhere I can obtain the utility? It does not seem to be available for download from Microsoft as a component.
ecmangen was removed from the Windows 10 SDK starting with version 10.0.16299.15. If you install an older version of the SDK (side-by-side installation is supported, so you can keep the newer versions as well), it will be available again.
I working on mfc application in which I need to check currently installed version Microsoft Visual C++ Redistributable.
Is there any way?
Each VS Version has its own redistributable files and they are named with a version number in the name.
So there is no "current" version. There may be several installations for different VS-Versions.
Usually the files are installed in the Windows\System32 directory for 64bit. So lookup the file you need and search for (i.e. MFC140u.dll) and you can determine it's version.
Also some programs may have a local copy of the runtime DLLs in their application directory...
I’ve written an application that inspects the customer installation. It works somewhat like the Microsoft Troubleshooters in that it identifies certain information about the user installation so that our tech support people can identify a potential problem with the customer installation. One of the things it reports on is the VC redistributables that are installed.
I accomplish this by interrogating the following LOCAL MACHINE registry key:
SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall
The code iterates through the sub-keys looking for a match on the “DisplayName” attribute of each sub-key. I look for “Microsoft”, “Visual”, “C++”, and “Redistributable”. If all strings are found, I collect the “DisplayVersion” attribute and report it to a dialog.
While this scheme will not indicate the "current" version, it should provide access to all versions that are installed.
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 !
I've been looking online and at my registry and I think not, but it would be nice if we could get a definitive answer on here.
Just the run time, as in for re-use on the client side.
I see it is possible for VC10, http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx, but prior to that we need to call the MsiQueryProductState API. Perhaps just give all the clients MSVCR100.DLL already?
The most common practice is to install the CRT your application was built with, regardless.
I think this practice comes from the v90 and lower CRTs, because there were multiple versions of each redistributable that could be installed, and though MSVCR90.DLL exists on the system, it may not be the version your application uses.
I believe this was changed with the v100 CRT, and now Microsoft guarantees that newer versions of the CRT will be usable in place of an older version, but I would still attempt to install the CRT your application was linked with.
It is still possible to do a private install of the Dll's into the application's folder. I recently installed 3 different version of the VC9 runtime when I was setting up my Visual Studio Express environments. All show up in Control Panel and appear to be readily removable.
For that reason I believe the current best practise to be to perform a private install (I think that is the terminolgy MS uses) of the required DLL's (for managed code you need the managed DLL and the native version) in tha app's folder.