I have an application that uses the OpenCV libraries. This application has to be installed on an old PC running Windows XP 32 bit. When running the application I got the error:
Kernel32.dll unable to import InitializeCriticalSectionEx
According to my searches, to fix this issue, I have to tell the compiler that the library will be used on Windows XP by setting the variable _WIN32_WINNT to 0x0501. I'm trying to apply the solution found in this entry in github, but I'm not very experienced with compilers and I'm having hard time to locate the files CMAKE_CXX_FLAGS and CMAKE_C_FLAGS. Can anyone explain me exactly what file I have to modify?
I'm using Visual Studio 2017 and Cmake on Windows 10.
I tried to use the toolset v140_xp in Visual Studio, but without success. At the end of the day, I got an old PC with Windows XP, installed Visual Studio 10 and tried to compile. The problem was that the latest version (3.4.1) won't compile for Windows XP. AFAIK, the most recent version of OpenCV that compiles for XP is 3.2. Probably it is possible to cross-compile it on Windows 10 using the v140_xp toolset, but I did not try as I already got the old XP with Visual Studio 10.
Related
I wrote a minifilter driver and I want it to run on windows xp.
Therefore I compiled it with platform toolset v140_xp and I noticed the file FltUser.h doesnt exists on Windows SDK version 7.1.
Someone know how I can use FltUser.h and still use SDK 7.1 (so it will support Windows XP SP2)
Thanks.
Have to ask this question once again here as none of the replies I found solve the issue.
So the goal is to set up the debugger for Qt Creator on Windows 8.1 x64. Visual Studio 2015 Update 3 (Community) and Qt 5.7 32-bit are installed on the system. As far as I understand I need Debugging Tools For Windows, which are a part of the Windows SDK. Visual Studio seems to install Windows SDK, but it doesn't have debugging tools. If I look into "C:\Program Files (x86)\Windows Kits\10\Debuggers" I see only one folder there, which is "x64" (and I suppose there must have been "x86" for 32-bit Qt). That folder contains three .dll files and no cdb.exe.
I tried to install Windows Debugging Tools manually as a part of Windows SDK, downloaded from here, but when I run the installer it gives me the error:
I guess that's because VS already has Windows SDK. Should I uninstall some component from Visual Studio? But I really don't want to break it.
Any help is appreciated
I'm running into problems generating a Visual Studio 2010 Express 64 bit project through CMake. I installed VS2010 Express first, then the Windows SDK 7.1 in order to be able to build 64 bit apps and then tried to compile my CMake project.
I do not remember this to be that difficult with 2008 Express, but with 2010 I fail again and again. 2010 searches per default for 7.0a SDK which is shipped with it. The express version seems to ship a reduced 32 bit version, which is located under
.../Program Files(X86)/Microsoft SDKs/Windows/7.0a
Windows SDK 7.1 64bit will be installed per default under
.../Program Files/Microsoft SDKs/Windows/7.0
In VS 2010 Express the platform SDK can be changed on a per-project-map basis and if I do so the inherited path macros surprisingly point to the correct SDK. The problem now is, that CMake is not happy about me screwing around in the project files by myself. Thus, it always resets the Platform SDK entry to the default value, which will make the Windows SDK point to 7.0a and result in complaints about missing 64 bit libs.
I now see two possibilities to resolve this:
Find a way to really integrate the 7.1 SDK into VS2010 Express, just like with VS2008. VS2008 searches the registry for the tag 'CurrentInstallFolder' in the Windows SDKs entry, and you can change this entry to point to another SDK.
Find a way to tell CMake (2.8.1) to set the correct Platform SDK in the project. No plan how to do this...
I would appreciate any help. 2010 is somewhat mandatory unfortunately, I personally cannot get used to it at all...
Ok, updating to the latest CMake (2.8.12) resolved this, CMake now detects the 7.1 SDK and sets it in the project files.
Edit: The toolset can be chosen in a CMake file via the CMAKE_GENERATOR_TOOLSET flag
I am trying to compile a C++ program using Visual Studio 2010 Pro on a Windows 7 computer to target Windows XP sp3 32 bits.
I've played around with the compiler and linker settings, but I'm unable to produce an executable that can run on my Windows XP computer. I always get the error "Could not find entry point for function GetTickCount64 in kernel32.dll" and the program doesn't run. I know Windows XP does not support GetTickCount64() and I'm not using it in my code anyways.
I don't have other versions of Visual Studio installed, and I already installed Visual C++ 2010 Redistributable Package on the windows XP machine.
Any idea on how to accomplish this?
Thanks before hand.
VC2010 targets Windows 7 by default.
To change target to XP, check Using the Windows Headers
I have a Windows 7 machine with Visual Studio 2005 SP1 installed. Using this, I build an application which loads a DLL at runtime compiled with VS2005 SP1 but on Windows XP. This fails, with the following error:
"...\foo.dll": The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
The DLL loaded is compiled against the debug CRT. The answer to this question hints that vcredist_x86.exe only contains release-versions of the CRT. I'm not sure if that is relevant in this case, since both my machine and the machine on which the DLL was compiled on both have the full VS2005 SP1 installed.
Should I attempt to rebuild the DLL on Windows 7 (I'd prefer not to), and will that cause the DLL to become unusable on the Windows XP machine?
Problem solved. The problem was that the Windows 7 machine did not have the KB971090 update which was installed on the Windows XP machine which built the DLLs. I had to explicitly tell Windows Update that I wanted to receive non-Windows updates in order to be able to install the update.