I have compiled a dll on Windows Server 2008 64 bit edition. It works fine on that version of Windows, but if I switch to Windows 7 or XP 64 bit edition the dll does not work. How can I make the dll compatible with all three versions of 64bit edition windows?
I am using Visual Studio 2010.
You can use a program called Dependency Walker to see what dependencies your .dll file has, and eliminate the ones that are different between versions of Windows.
Check how _WIN32_WINNT and WINVER macros were defined in your DLL. To make your DLL compatible with Windows XP you should define them as 0x0501. That lets you find all dependency problems at compile time. More information about these macros you could find here.
Related
I'm using visual studio 2013 and compile something to run it on windows XP. It runs fine on my windows 10 machine but when i start under XP i get the error:
the procedure entry point "SHGetKnownFolderPath" could not be located in the dynamic link library shell32.dll
The options in my vs-project are set to XP variant (v120_XP). I also tried to set _WIN32_WINNT (and other defines i found on the internet) to XP define variants (e.g. _WIN32_WINNT=0x0501) without success.
I'm using some libraries which are all compiled unsing v120_XP (e.g boost).
Any advice is welcome to get my project running on windows xp.
UPDATE:
Sorry my fault. Even all libraries were forced not to use anything what is not provided by XP i missed one library which was not compiled by myself is using SHGetKnownFolderPath. I found it by dumpbin-ing all libraries. it was SimConnect.lib, used for Prepar3D. Later i found:
Prepar3D v2 is not
compatible with Windows XP and is not recommended on Windows Vista.
SHGetKnownFolderPath does not exist in XP, it's only available in Vista and above.
I have a big native C++ project which is build by many specific and 3rd party libraries in Visual Studio 2013.
I am compiling for both 64 bits and 32 bits architecture.
For the 32 bits architecture I set (for both the 3rd party and our libraries) the XP toolset (v120_xp) to keep the compatibility with Windows XP.
Recently we have updated a library and from the error we receive it looks like some of the library has not been set properly for XP. Is it possible with Dependancy Walker or other tools to detect which is the toolset used to build the DLL or the EXE?
I just need any way to check which library is not XP compatible.
Use dumpbin /headers my_program.exe and look for the operating system version and subsystem version. When building for Windows XP they will be 5.01. When not building for Windows XP they will be 6.00.
(This isn't foolproof--if the DLL or EXE declares that it runs on Windows XP but tries to use Windows APIs that are not available on Windows XP, then obviously the DLL or EXE won't run on Windows XP.)
I compile my C++ source code with Visual Studio 11 Developer Preview. I statically link to the runtime library.
The resulting executable cannot be executed on Windows XP. When I try to execute it on Windows XP I get the error message "[Executable Path] is not a valid Win32 Application.".
According to Microsoft Visual Studio 11 won't support Windows XP.
How does it work that the resulting executable cannot be executed on Windows XP? Is there anything special within the executable?
They seem to drop support for older systems in every new release of VS (NT4,2000,XP) Even if you don't use the CRT at all, they still force the PE subsystem version to high numbers. You can work around that by changing the numbers back to 5.0 in a post build step. Just changing those numbers should allow the exe to start on XP unless the new CRT is using WinAPI functions that don't exist on XP.
The other alternative if you want to keep using VS11 is to use multi-targeting and older compilers...
Visual Studio 2012 will be able to target Windows XP later in 2012:
Targeting Windows XP with C++ in Visual Studio 2012
"Later this fall, Microsoft will provide an update to Visual Studio 2012 that will enable C++ applications to target Windows XP. This update will make the necessary modifications to the Visual C++ 2012 compiler, runtime, and libraries to enable developers to create applications and DLLs that run on Windows XP and higher versions as well as Windows Server 2003 and higher."
Edit: This has now happened (phew!)
The workaround is to use a different Platform Toolset, which will link a different version of CRT and produce binaries compatible to older operating systems.
See more here: Target Windows XP in Visual Studio 11 Beta using the Visual Studio 2010 compiler and libraries.
With v90 toolset your binary will be able to run even in older systems, such as Windows 2000.
http://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-65-69/7444.BlogPic.png
The runtime libraries bundled with VS 2010 and higher enforce your executable to import two new functions from kernel32.dll that are missing on Windows XP: EncodePointer and DecodePointer. Those are needed for yet another idiotic naive attempt to enhance the software "security".
In VS 2010 there is an option to use the runtime libraries of Visual Studio 2008, which solves this problem. I don't know if there's such an option in later versions of VS.
I compile my C++ source code with Visual Studio 11 Developer Preview. I statically link to the runtime library.
The resulting executable cannot be executed on Windows XP. When I try to execute it on Windows XP I get the error message "[Executable Path] is not a valid Win32 Application.".
According to Microsoft Visual Studio 11 won't support Windows XP.
How does it work that the resulting executable cannot be executed on Windows XP? Is there anything special within the executable?
They seem to drop support for older systems in every new release of VS (NT4,2000,XP) Even if you don't use the CRT at all, they still force the PE subsystem version to high numbers. You can work around that by changing the numbers back to 5.0 in a post build step. Just changing those numbers should allow the exe to start on XP unless the new CRT is using WinAPI functions that don't exist on XP.
The other alternative if you want to keep using VS11 is to use multi-targeting and older compilers...
Visual Studio 2012 will be able to target Windows XP later in 2012:
Targeting Windows XP with C++ in Visual Studio 2012
"Later this fall, Microsoft will provide an update to Visual Studio 2012 that will enable C++ applications to target Windows XP. This update will make the necessary modifications to the Visual C++ 2012 compiler, runtime, and libraries to enable developers to create applications and DLLs that run on Windows XP and higher versions as well as Windows Server 2003 and higher."
Edit: This has now happened (phew!)
The workaround is to use a different Platform Toolset, which will link a different version of CRT and produce binaries compatible to older operating systems.
See more here: Target Windows XP in Visual Studio 11 Beta using the Visual Studio 2010 compiler and libraries.
With v90 toolset your binary will be able to run even in older systems, such as Windows 2000.
http://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-65-69/7444.BlogPic.png
The runtime libraries bundled with VS 2010 and higher enforce your executable to import two new functions from kernel32.dll that are missing on Windows XP: EncodePointer and DecodePointer. Those are needed for yet another idiotic naive attempt to enhance the software "security".
In VS 2010 there is an option to use the runtime libraries of Visual Studio 2008, which solves this problem. I don't know if there's such an option in later versions of VS.
I'm fixing a bug with Windows Vista 64 bits of a 32bit application, when I try to use the function Wow64DisableWow64FsRedirection(...) the compiler says 'undeclared identifier...'.
I'm including the Windows.h header file and set _WIN32_WINNT to 0x0501.
Any ideas?
Thanks.
EDIT: We're using MS Visual Studio 2003
Your platform SDK files are probably too old to have that function. That function first appeared in the XP 64 bit platform SDK. You can get the latest SDK here: http://www.microsoft.com/downloads/details.aspx?FamilyID=e6e1c3df-a74f-4207-8586-711ebe331cdc&displaylang=en
Even though it says it's "The Windows SDK for Windows Server® 2008" it is just the latest SDK and will have all the backwards compatible files you need.
After you install it, depending on your compiler you'll probably have to point the include directory to it.
Can you see this API in the header file? May be the Visual Studio you are using is not having updated header file, in which case you will need to do a LoadLibrary for Kernel32.dll and then GetProcAddress for the required function.
If your application needs to work on Windows XP 32-bit or Windows 2000, you should use LoadLibrary() and GetProcAddress() as Canopus suggested, because Wow64DisableWow64FsRedirection() and Wow64RevertWow64FsRedirection() were not added until Windows XP 64-bit and Server 2003 SP1 (according to the documentation).