In my previous blog I talked about how in Visual Studio 11 we have eliminated the need to convert your Visual Studio 2010 C++ projects in order to adopt the new IDE. The blog also mentioned that you can build your projects using Visual Studio 2010 compiler (tools and libraries) from within Visual Studio 11 using the multi-targeting feature. This means while you adapt to using the new compiler and while your 3rd party vendors provide you with binaries compatible with the Visual Studio 11 compiler (tools and libraries) you can leverage the new Visual Studio 11 IDE without disrupting your ship cycle. Just set the platform toolset property to v100 in the property pages (requires Visual Studio 2010 to be installed side-by-side with Visual Studio 11). Since no upgrade of your project file is necessary you can continue to load the project/solution in Visual Studio 2010 as well.
We have recently received feedback from a number of customers about the inability to build binaries that run on Windows XP with the Beta version of the Visual Studio 11 compiler and libraries. This is because the C++ compiler and libraries in Visual Studio 11 Beta leverages platform capabilities only available in Windows Vista and higher. However, if support for Windows XP targeting is important to you, then you can use Visual Studio 11 Beta’s multi-targeting capability described above in order to employ the Visual Studio 2010 compiler and libraries to build applications and libraries than execute on Windows XP. This enables you to enjoy the new features of the Visual Studio 11 Beta environment without sacrificing backward compatibly in your applications!
Must have: better C++11 support with the ability to target XP SP3 through the VS11 compiler. Otherwise we don't see a reason to upgrade until official end of XP support in 2014 (or even later, our customers decide).
Good to have: stable and responsive IDE
Nice to have: improved intellisense, refactoring tools, unit tests, compile time and runtime performance improvements
If Visual Studio 11 will not allow targeting Windows XP when using the new C++11 language and library features, there is absolutely no value in it for our codebase and team. We may just as well continue to use Visual Studio 2010 until the share of XP users is sufficiently low (think of <5%, not ~27%).
Hopefully we will not have to skip it. But things don't look too bright at the moment.
I'd like the simplicity of an integrated solution, just bundling the old toolchain would be good enough. Won't use the new C++11 features.
By the way: 62.9% of my customers are on 7, 28.4% are on XP, 8.5% on Vista and 0.2% on other version (server releases). From my point of view you should keep XP support, but could remove support for Vista...
My conclusion is that Microsoft wants us to migrate our applications written in C++ to C#.
For instance, we can write .NET 4.5 applications in C# that run in Windows XP.
BTW, I can use multi-targeting for XP with the new IDE because I will not use the new C++ 11 features.
"see my comment to jalf above clarifying my point on using SSE with XP."
Our software is very resource intensive, so we probably wouldn't run on XP minimums either. Remember that it is only VERY recently that PC makers stopped selling machines preloaded with XP.
"I'm certainly not here to debate or defend of the lack of XP targeting in Dev11 Beta; I'm here to understand the specific benefits customers are seeking with XP targeting."
Let's turn this on its head. We the developers would like to understand the specific benefits that Microsoft is seeking with the removal of XP targeting. So far we have not seen a single reason for doing so.
"Let's turn this on its head. We the developers would like to understand the specific benefits that Microsoft is seeking with the removal of XP targeting. So far we have not seen a single reason for doing so."
The lack of XP support seems not to be a technical decision, but rather an order from higher up.
This is a joke.
No way I am going to advise people to spend the amount of money Visual Studio costs, to work in such a setup if they still need to target XP.
The Visual Studio team seems to play around with features (intellisense, color printing, C++ tooling, C99), and keeps saying to us "just buy this version and we will fix it on the next version".
What about we just giving the money to a compiler vendor that really listens to their customers?
You're insane if you think anyone is going to pay money for a compiler that can't support 30% of their customers. Flat-out insane. People will be more likely to spend the time and money to switch to a different compiler with C++11 support, like Intel's or GCC.
Long time, no see...
Me and my team don't hold much hope for VC11. We have tentatively decided that we aren't going to use it, barring some miracle which would turn the development priorities around to where we think they should be.
Why? Three reasons:
1. Lack of support for XP. This is an absolute show-stopper. We can't force our customers to upgrade and we won't leave them in the cold, losing money and trust.
2. Lack of support for C++11. There is next to nothing on that front in the planned release of VC11. We are aware of the plans to add variadic templates sometime before the next version, but that's too little, too late, and, quite frankly, might not happen.
3. Poor performance of the IDE on large projects. This is NOT FIXED in the beta. The current beta of VC11 is every bit as slow as VC10 on large C++ projects. You say you hear us on the performance side and you worked on it, well, we just don't see it. OK, the IDE starts faster, fine, but what else have you got? What else? Whatever it is that the beta was supposed to make faster, we are just not seeing it.
There are a couple of other serious issues, like, well, bugs (see my nick, it's there for a reason), but the above three are the main ones.
Yep, this blog post is totally insane. It is perhaps useful for two or three guys who'd want to use VS11 just for the IDE with the old compilers, and who didn't yet know that they could do this. The post, however, is insulting to the rest of us, C++ developers, who have been saying that our main interest is C++11, not bells and whistles in the IDE, over and over and over again.
For those wondering about the reason for dropping support for XP in the first place, here it is:
The CRT started using several new functions which can only be found in Vista+. The team could have done LoadLibrary / GetProcAddress and only use these functions if they are present, falling back to previous code on XP, but this got into a conflict with the desire to have the same CRT for both regular apps and Metro apps. You can't do LoadLibrary / GetProcAddress in Metro, this is prohibited.
In my opinion, having the same CRT for both regular apps and Metro apps is not important. Since these two worlds are already so different (as in, you are either a regular app or a Metro app, not both, and certainly not switching from one mode to the other), having two different flavors of CRT for these modes would have been fine. Why the team thought having a single CRT is so hugely important, more important than being able to support Windows XP is beyond me.
It seems that there is a straightforward solution: Split the runtime library.
VC++ applications have used a split runtime library since MFC was released. There's MSVCRTxx.DLL and MFCxxxx.DLL.
Make MSVCRTxx.DLL work on XP. That's where all the C++11 library work is anyway. Any features that can't work on XP, split to a separate DLL. MSVCGRxx (GPU runtime) or something, which works on Vista and later. And MSVCMR (Metro runtime) if needed, which requires Win8 or later.
Split the MFC library too, if you think anyone cares about it. I don't. If the new MFC requires Vista+, it won't bother me in the least. But find out from customers who actually use it whether MFC.next needs to load on XP.
At least according to the documentation, GetProcAddress should work in Metro apps. In that case, new functions in Vista+ could be handled without issues (LoadLibrary can't be used in Metro apps, but kernel32.dll/user32.dll will be loaded regardless, so it shouldn't matter).
Does this restriction in Visual Studio 11 also apply to Windows Server 2003 and 2003 R2 (because XP uses a similar technology than Server 2003)?
PleaseFixYourBugs, the new CRT actually does use GetProcAddress still, to make decisions based on whether the OS is Vista, W7 or W8. However, they stopped using GetProcAddress in parts of the CRT where it was previously used. They basically ripped out the logic that previously allowed the CRT to function on XP.
Multiple people, including me, have done proof-of-concept modifications to the VC++11 generated executables to show that they indeed can work fine on Windows XP if the CRT was written correctly. One such solution has been published by a guy named Ted. There are no technical reasons behind the CRT not supporting XP.
I hope the VC++ team listens to our posts in this blog. On their side it's only a 2-3 hour job to do the required modifications to make the CRT work on XP.
@fmunkert: Yes. At the moment, Windows Vista or higher is required by the VS11 CRT.