What if I don't compile DLLs with vs110_xp? - c++

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.

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.

Visual C++ Compiler Flag for Visual Studio 2013 for Targeting XP

I want to create a C++ program with Visual Studio 2013 targeted for the XP environment, I am aware of the UI option in Project Properties -> Configuration tab to set the the Platform Tool set top Windows v120_xp, I want to acheive that using the command line options. How to do that.
For visual studio 2012 I am aware of the option
set CL=/D_USING_V110_SDK71_;%CL%
I am looking for similar option is Visual Studio 2013. Can you please help?
The _USING_V110_SDK71_ macro has nothing to do with building your program to be compatible with XP, it is merely a side-effect. The essential option is a linker option, /SUBSYSTEM. Note how this option lets you specify the major and minor sub-system version number. Your program can only run on XP if you set this option to 5,1. Starting with VS2012, the default setting is 6,0 which is the version number of the current generation of Windows. Vista or higher is required to run such a program.
This is actually rather a big deal, downgrading the version number turns on some app-compat shims in Windows that were designed to deal with a program that announces that it doesn't know anything about a modern Windows version. Particularly the way Aero lies about the window metrics, designed to allow an ancient program to still run with fat window borders.
The CRT is also affected, fairly obscure details related to threading and localization. Testing is required of course. Keep the cost of supporting such an ancient operating system in mind.
Last but not least, you also need to use an appropriate SDK version. The last one that's still compatible with XP is v7.1. If you build from the command line then you'll get 8.1, you need to fix that by setting the %WindowsSdkDir% environment variable first. And you need to set the target Windows version in your headers that #include Windows.h, hopefully a precompiled header. Define _WIN32_WINNT to 0x501 to match XP and avoid accidentally using winapi functions that are not available on XP.

Can I deploy for Windows 2000 using Qt 4.8.4?

I have created an application using Qt 4.8.4, and now I have to distribute it on Windows 2000 machines, among the others. I have already tried searching over the Internet for a clear explanation about it, but I can't find a confirmation on what's the older Windows version actually supported by Qt.
The application runs fine on Windows XP (both 32 and 64 bit) and Windows 7 but, when I try to launch it on Windows 2000 I receive the well-known error "[Application name].exe is not a valid win32 application.", and I guess that the error relies on the unsupported Windows version.
The application is a "simple" one, it just need QtCore4.dll and QtGui4.dll as dependencies.
If it can help, I am developing on a Windows 7 64 bit machine, using Qt 4.8.4 and Qt Creator 2.7.1. If I go under Tools->Options->Build&Run->Kits->Manual->Desktop, I have "Microsoft Visual C++ Compiler 10.0 (x86)" as the compiler in use. Do I have to select a different one, maybe?
Thanks for any answer.
EDIT: What I've done after reading #vahancho's answer:
"Move" the project from Qt Creator to Visual Studio 2010, using CMake;
Install Visual Studio Express 2008 (enabling the V90 Platform Toolset, this way)
Open the project from VS2010, and go under Project Properties->Configuration Properties->General and change Platform Toolset to V90;
Recompile the project;
Now, I've tried to run the application compiled this way on a virtual machine, mounting Windows 2000, but I get another error, this time: "The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll".
Well, after some investigations I found that running MSVC10 applications on Windows 2000 is not possible. You have to build it with at most MSVC9 (Visual Studio 2008), or use the VS2010 Multi Targetting feature to let VC++2010 use the VC++2008 compilers and libraries. Please also refer to this Microsoft Connect discussion.
OK, some time has passed, but I'd like to give a definitive answer to this question of mine. Unfortunately, what I was asking for it's not possible. #vahancho's answer is right, and the solution he pointed out is correct for the majority of situations. However, DecodePointer is "included" in Windows XP SP 2 kernel, and it's not possible to compile an application using it for an older Microsoft OS, even by choosing the VC++2008 compiler.
An additional reference is given by this post on CodeProject.
Fortunately for me, my application was simple enough to let me rewrite it using the good old VB6 :)

"Unable to load DLL ... The specified procedure could not be found" C++ on Windows XP

I have a largish multi-module program that includes a DLL for a C++ program. This worked fine for many years, also on Windows XP. Don't usually test the program on Windows XP, but after a pause of a year or more (during which time lots of things were happing to the non-C++ parts of the program) I did test it, and now it was failing with the exception ""Unable to load DLL ... The specified procedure could not be found - HRESULT 0x8007007F". Tried all sorts of things, and eventually found the solution - see the answer below.
During the period when I hadn't tested on Windows XP I'd upgraded my development system from Visual Studio 2010 to 2012, and hadn't noticed that Microsoft had deprecated C++ support for Windows XP! Fortunately, they "upgraded" (downgraded?) VS 2012 so it supported Windows XP again in "Update 1". But you have to modify the project settings to get it to work.
All of this happened late last year, and I was blissfully unaware of it. :-(
http://blogs.msdn.com/b/vcblog/archive/2012/11/26/visual-studio-2012-update-1-now-available.aspx
http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx

C++ program works on XP SP2 only after installing Visual Studio

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.