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).
Related
I have an application written in C++ that uses socket (Winsock2.h). It has been developed on Windows 10 and it builds and runs fine on Windows 10. There is an old XP machine on which that application has to run (the machine cannot be upgraded as it contains legacy code that does not run on newer systems), but when I try to run the application on it I get the error: "The procedure entry point WSAPoll could not be located in the dynamic link library WS2_32.dll".
I tried the following:
I downloaded Visual Studio Express 2010 on a XP box and tried to build the application on it:
The code does not compile, because it uses libpqxx library (I suspect that libpqxx uses some c++11 code, that is not fully supported by VS2010);
I downloaded the XP toolset (v141_xp) for Visual Studio 2017 and built the application on Windows 10 (I have also downloaded and installed on XP the Microsoft Visual C++ Redistributable for Visual Studio 2017);
I got the same "The procedure entry point WSAPoll could not be located in the dynamic link library WS2_32.dll" error.
I tried to use winsock.h and link the application to wsock32.lib:
I got the same entry point error on WS2_32.lib (probably VS links the application to WS2_32.lib even if I specified to use wsock32.liB).
Is there a way to build on VS2017 using the xp toolset an application that uses Ws2_32.lib targeting XP?
EDIT 2019-05-03 10:30
As noticed by cprogrammer and Remy Lebeau WSAPoll does not exist in XP. The point is that I do not use WSAPoll in my code. So I followed the suggestion of Retired Ninja and I wrote from scratch an application using WinSock2 starting from the very basic and adding functions step by step(*). Well, all of my code worked well. The point is that I included also another library - libpqxx - and probably it uses WSAPoll.
Ok, I still have a problem, but at least I know where it is
(*) By the way, I already tried the same in the part of my code that uses WS2_32.lib, but as the problem was in another library I still got the error, so the suggestion to start from scratch really helped.
Accortding to docs, for WSAPoll, the minimum supported client is Windows 8.1, Windows Vista [desktop apps | UWP apps]
Cannot be used for applications targeting Windows XP.
Your app (or one of its dependancies) is static linking to WSAPoll(), which simply does not exist on XP, it was introduced in Vista. Whatever code your app uses that utilizes WSAPoll() will have to be rewritten for XP. For instance, by using GetProcAddress() to access WSAPoll() dynamically instead of statically, and using a fallback (select(), WSAAsyncSelect(), WSAEventSelect(), etc) when WSAPoll() is not available.
Actually, the code should be rewritten - period, since WSAPoll() is broken and even Microsoft has gone on record saying that WSAPoll() will not be fixed and should not be used.
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.
In my application I need to check windows version. I'm using Version Helper functions in Visual Studio 2013 (v120) platform toolset. But then the program does not work in Windows XP. error is:
'xxx.exe' is not a valid win32 application
So I changed platform toolset to Visual Studio 2013 - Windows XP (v120_xp). But in this case application will not compile.
The error is:
error C1083: Cannot open include file: 'VersionHelpers.h': No such file or directory
What can I do? Can I use old GetVersionEx function? MSDN says:
GetVersionEx may be altered or unavailable for releases after Windows 8.1. Instead, use the Version Helper APIs
But may be I should use it for now!
I've managed to solve it using Remmy Lebeau's comment.
I copied VersionHelpers.h from C:\Program Files (x86)\Windows Kits\8.1\Include\um and winapifamily.h and sdkddkver.h from C:\Program Files (x86)\Windows Kits\8.1\Include\shared into my project and changed some includes in them.
Now it compiles with Windows XP toolset.
I've tested it and it's working as expected in all versions of windows.
How about this: try to link the functions manually with GetProcAddress to see what is available, If the new API is not, then the old must be, so you can use the one you managed to link without errors.
I am assuming you are building 32bit or 64bit and the OS in both cases is compatible.
EDIT:
GetVersionEx(), here is exported from kerner32.dll in XP, so you can try to link it using
GetProcAddress() here also has a suggestion by Microsft using "GetNativeSystemInfo".
The new API function
IsWindowsXPOrGreater() // also exported from kernel32.dll and ntdll.dll
can also be linked the same way using GetProcAddress(). This function will return an error if the function you are trying to link is not found, so you will know which one you have available. Then you call the available one and get the version info you need.
You only need to define the function prototypes yourself instead of using the headers, then define two function pointers, one for each, then assign them a NULL value initially until you try to link the functions. Then one pointer (or both) will end up with a value, and you can use the latest one available to call the linked API.
I use visual studio 2010 running on Windows 8.1
the program is in C++ and uses MFC library
when I compile it in my computer running windows 8, and then I run it on the destination computer running windows 7, the program stops unexpectedly.
how to compile it specifically for windows 7
Without using a newer SDK there is no special switch to set to compile a program for Windows 7.
Read aboutthe SDK versions and settings for the header files in the [MSDN][1]
Even if you use a newer SDK and it is a standard MFC program, than you shouldn't have a problem using it under Windows 7. In 99% of all cases using a newer SDK (with incompatible compiler settings) and run the program on an incompatible (older) OS, the program will not start. In such cases some DLL entry points of new function can't be found.
If you program stops unexectable you should use remote debugging to find the bug. Or use minidumps to do a post mortem analysis. I am sure you have a bug in your program. And that it runs on Windows 8 may be simply luck.
Check if the values of WINVER and/or _WIN32_WINNT in your project have been #defined as 0x0602 or higher -- see this MSDN article for a list of possible values
It might be an issue of the runtime libraries not being present on the Windows 7 machine. This can prevent the program from starting with a non-intuitive error message.
In that case, you can install the Visual C++ 2010 Redistributable Package on the Windows 7 machine and see if that helps. Alternatively you can deploy the application with the runtime library DLL files in the same directory as the .exe.
I have a dll project project in my solution, in which target OS version is not defined.
even have the following warning:
_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)
this might be the problem. After testing it I will confirm the answer
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.