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.
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 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
By default Visual Studio 2012 does not support Windows XP nor Windows Server 2003. And before Update 1 those OSes weren't supported at all. Now with Update 1, I can use Visual Studio 2012 to create apps that target Windows XP and Windows Server 2003 by choosing to use the vs110_xp toolset. Great.
I wonder what happens when I forget to do that? What does "does not support" mean? Executables just don't run: "... is not a valid Win32 application."
But what will happen when I use such DLLs on XP? I cannot seem to find any information about that. And unfortunately I currently cannot try it out. Anyone found specific issues?
The program simply won't be able to start and fails immediately. The most important change in VS2012 is that it now specifies Windows version 6.0 in the /SUBSYSTEM linker option. Window XP will notice this, it is version 5.02, throw up its hands and fails the EXE start request or DLL load with ERROR_BAD_EXE_FORMAT.
Pretty important change btw, the appcompat shims that Windows turns on for executables that say that they were made to work on old Windows versions are fairly troublesome. The Aero lies are hard to deal with, should you care. The CRT was changed a great deal as well, using many more winapi functions that are only available in 6.0 and up. The Update1 revision limps along when it discovers them missing.
I have a C++ program. It's quite simple - shows an image (splash screen) and launches another application, then closes when that other application is started. Actually, this one: http://www.olsonsoft.com/blogs/stefanolson/post/A-better-WPF-splash-screen.aspx with very minor changes (my splash screen image and my program is launched instead of the sample one).
It works good on my Windows 7 developer machine. Also it works on another (virtual) machine with Windows XP SP2 and Visual Studio 2008 installed. But it doesn't work on just the same virtual Windows XP SP2 machine without Visual Studio. It shows an error: "Entry point memmove_s could not be located in the dynamic link library msvcrt.dll".
I have found that a problem possible is in WindowsCodec DLL (no such DLL in clear XP SP2 installation, but it is in Windows/system32 folder of XP SP2 with Visual Studio) so I copied it to the application folder on the clear system. After that the program partially works (launches another application after start) but didn't show the splash screen image.
Installation of Microsoft Visual C++ Redistributable Package (both 2008 and 2010) didn't help.
I've found a recommendation to use static linking in Visual Studio (Multi Threaded (/MT) option in project properties -> C/C++ -> Code Generation), but it also didn't help.
Also I have tried DependencyWalker but cannot find any differences in dependencies for both test systems.
Anyone have any ideas why this could happen? I'm completely new in C++, hope this is something obvious that I just don't know...
Your program has a dependency on the .NET framework, at least version 3.0. That is not available on an XP SP2 install by default. If you don't see windowscodecs.dll then you didn't install the proper version of .NET. This does work when you install VS2008 because it also installs .NET.
The download is here.
C++ programs become dependent the specific versions of the crt library that it was compiled on. If the running system does not have that version in the either the local program directory, or the systems WinSxS directory. This is a specific issue with C++ progams compiled using VS 2005 or 2008. See here for more information : http://en.wikipedia.org/wiki/Side-by-side_assembly
You might see this problem go away if you use VS 2010, as it uses a different method for dependency resolution.
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).