I installed VS 2012 Professional and the XP update as well. I built my project with v110_xp as the platform toolset on VS 2012. My project's .msi package is installing fine on Win 7 but failing on Win XP SP3. The error reported on XP SP3 is -
"The procedure entry point FlushProcessWriteBuffers could not be
located in the dynamic link library Kernel32.dll".
While the same project built from VS 2005 is installing fine on XP SP3. I am not sure what is going on VS 2012. _WIN32_WINNT is set to 0x0501. Can some one please guide as how to resolve the problem ?
Any help is highly appreciated,
Mahesh.
Yes, the C Runtime has a dependency on FlushProcessWriteBuffers(). The updated version of msvcrt110.dll and libcmtl.lib, the ones you got along with the update, no longer directly link to the function, they use GetProcAddress() to find it and limp along if it is missng. So you should never get this error.
So very high odds that you deployed the wrong version of msvcrt110.dll, an old one instead of the updated one. You can find it back in c:\windows\system32, look at the properties. Mine is version 11.00.51106.1, dated 11/5/2012. A separate installer is available for it here.
The VS2012 runtime that you are installing uses functions that are not present available in XP. See this MS article: Targeting Windows XP with C++ in Visual Studio 2012 which explains more and provides some workarounds.
Update 1 for VS2012 resolve the problem.
But Update 1 isn’t just about new Windows platforms. It also enables you to target Windows XP with native C++ applications in Visual Studio 2012.
If you are building with update 1 and still encountering problems then I suspect that you are installing an out of date runtime. You need to deploy the runtime delivered with update 1.
You can solve this by including the VC11 merge modules from your development machine(program files\common files\merge modules) in your installer. It's easier than having to run the redist exe in your installer.
If you use WIX: merge module addition
I've tested on server 03, xp64 and xp32.
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 trying to create a C++ DLL to register with Terminal Services to provide virtual channel functionality. Unfortunately the header CChannel.h cannot be found.
I'm using Visual Studio 2012, which is targeting Windows SDK 8.0. Sure enough, the required header is missing. However, it is present in the 8.1 \include\um directory
Reinstalling the SDK has not changed matters. Manually referencing the 8.1 include directories causes all sorts of issues.
Is there a simple way to get these headers installed under 8.0?
This seems to be a problem others have encountered before, without a direct resolution.
Oddly, cchannel.h is only missing from Windows SDK 8. It is present in SDK 7 and SDK 8.1.
I resolved the problem by using the v110_xp platform toolset. This targets a version of the Windows 7 SDK, but uses the latest compiler (as of VS2012).
VS2012 Update 4 must be installed to access this toolset. More details can be found here.
Last week I inherited a legacy unmanaged C++ application.
Unfortunately the project settings are not 100% reliable, and there is no documentation. What I do know is that the product was deployed with Microsoft Visual C++ 2008 Redistributable x86.
My question is: what combination of IDE, SDK, and Platform ToolSet would you recommend using?
Unfortunately I haven't worked with the Windows SDK before, and the Platform ToolSet option is new to me. To make matters worse, I haven't written a line of C++ code in eight years! So... any feedback you can provide would be greatly appreciated :D
KNOWNS
Client Operating System
Windows 2008 R2
C++ Redistributable
Microsoft Visual C++ 2008 Redistributable x86 is deployed in production
Integrated Development Environment (IDE)
I would prefer to use Visual Studio 2012 (we also have: Visual Studio 2008, 2010, 2012)
UNKNOWNS
Platform ToolSet
Can I use VS2012 and target the v90 platform, or is it more stable to simply use VS2008?
Windows SDK
Which version of the Windows SDK should I install on the development machine if the client is using Microsoft Visual C++ 2008 Redistributable x86 in production?
I would start by trying to get the project to compile successfully in Visual Studio 2008, since you mentioned you already have that available.
I wouldn't bother trying to install another version of the Windows SDK (one comes bundled with VS 2008) unless you can't get the project to compile successfully in an out-of-the-box install of VS 2008. If not and you do want to try installing another version of the SDK, I would opt for version 7.1, the one that targets Windows 7.
There is unlikely to be any advantage in using version 6.1 of the SDK; new versions might add new features, but they generally retain backwards compatibility with the old versions. I would not, however, install any version of the Windows 8 SDK because that might end up confusing you as the developer.
Once you get everything up and going on VS 2008, you could try switching over to VS 2012 if you'd prefer to use it. (I still can't get used to the UI, but apparently someone likes it.) As you point out in the question, the easiest way of making this work correctly would be to target "v90", which is VS 2008 (set using the Platform Toolset option). That will basically allow you to use the VS 2012 shell for editing purposes, but the VS 2008 compiler and headers for builds. You won't get any of the C++11 features introduced with VS 2012, however, because you're not using the new version of the compiler; you'll be stuck with what was supported back in VS 2008.
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
I have a lot of projects done with VS2010 in C++. Now we have switched to VS2012 but we want to continue building the projects with the VS2010 runtime (we need to support Windows XP).
To our understanding this could be possible using Windows SDK 7.1 as the VC compiler is there so we installed it. VS2012 recognized the SDK and now we have a Platform Toolset named Windows7.1SDK.
The problem comes when building the projects as some projects are returning a:
error MSB6006: "CL.exe" exited with code -1073741515.
Also, projects depending on the MFCs are failing too. MFCs aren't available with Windows SDK? Does this mean that we need to buy VS2010 licenses to install them on machines with VS2012 just to build using the VS2010 compiler?
Thanks in advance.
Looks like it's not possible at all, mainly because nothing but VS2010 is deploying the MFC libraries and we have a lot of projects using them.
We'll have to buy licenses for VS2010 and VS2012 :S
I would try raise the msbuild verbosity level (it is in Tools->Options->Project and Solution-> MSBuild) and check out the command of CL.exe with full parameters. Then check if it is different from what you saw on VS2010.
In fall Microsoft will release an update to support windows xp in visual studio 2012, you can read more in this MSDN blog:
http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx