Compile C++ program to run on windows 7 using VS2010 running on windows8 - mfc

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

Related

How to build a Winsock2 (WS2_32.lib) application targeting Windows XP with Visual Studio 2017

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.

Targeting the Windows 7 OS with Visual Studio 2017 gives a ucrtbased.dll missing error

I have a client that is running a Windows 7 machine and I want to him build an .exe that he can run on his computer. However, since I am running Windows 10, I am building everything in Visual Studio 2017. The program I am making is a Winforms CLR C++ program. I put in the Windows 7 WINVER define in one of the C++ files:
#define WINVER 0x0601
The compile the project with the following properties:
I send him an .exe file but when he opens it up, it gives him a an error saying that he is missing the ucrtbased.dll. I verified that he has the correct .NET framework installed on his computer:
What could be the cause of this?
Build and send him a release copy. He will still need the appropriate windows libraries.
ucrtbase (Universal C Runtime) is the replacement for the msvc* runtime dlls.
To get the correct runtime, see https://www.microsoft.com/en-us/download/details.aspx?id=48234
and also possibly https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows
if you have problems.

the procedure entry point SHGetKnownFolderPath shell32 not located

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.

Incorrect C++ runtime components

I have a vs 2008 c++x32 build and when I tried to run it on a fresh windows 7 vm install, I get the following error:
"WINDOWS 7 error The application has failed to start because the side
by side configuration is incorrect please see the application event
log or use the command line sxstrace.exe tool for more detail."
I have found the following resolution:
The machine is missing the correct C++ runtime components for your
type of system. (x86 or x64). Installing the following update resolves
the issue. Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)
As details about the vs 2008 solutions: i use unicode, I don't use ATL or MFC just Standard Windows Libraries.
My question is: am I doing something wrong? is this normal or there is a way of overcoming this problem from the development phase. What must I do so that my program would run the first time.
All programs compiled from Visual Studio needs a runtime library (the library that actually contains the functions used by new, delete and other runtime support functions). This runtime library needs to be there when you run your program. Either by you installing the shared libraries, or by you making your project a statically linked project so the runtime is linked to your program.

Visual Studio 2012 Project targeting Windows XP using MFC

I have recently acquired source code from a VS2005 project that uses the MFC library. Firstly I upgraded the project to VS2012 and I can now successfully build and run the software on Windows 8. Next, I wanted to deploy the software on a Windows XP machine.
I have set the Platform Toolset to build to Windows XP (using the v110_xp option) and I have installed the 'Visual C++ Redistributable for Visual Studio 2012 Update 1' on the target machine. When I run the software, nothing appears to happen. Via some logging functions I can determine that a call to LoadFrame(IDR_MAINFRAME) causes an exception in kernel32.dll. I can't debug any further in to LoadFrame as remote debugging on Windows XP is not available in VS2012.
Any ideas what may be going wrong? Is the Visual C++ Redistributable package the correct version to be installing on the target machine? What should I be trying next?
UPDATE
My project is already set up to use the 7.1 SDK and has minimum required version set to 5.01 in linker options.
If I use InstallShield to generate an installer and include the MFC, CRT and ATL redistributables, the installer works and my program now runs on Windows XP. My understanding of the redistributables is that they simply copy the relevant dll's in to the system32 folder (or equivalent)? Is that correct?
However, if I simply copy the files over, run the vsredist_x86.exe or use Inno Setup to install the software & dll's, my program no longer works.
I believe you have read this blog. In summary, you need to use the 7.1 SDK, and you need to set minimum required version to 5.01 in linker options.
Using the working InstallShield project and the not-working Inno project I was able to determine that the real culprit here was an unregistered msxml4.dll. The error I was receiving gave no real clue to this outcome but I got there eventually...
regsvr32 msxml4.dll