Search

Bug: apps created with CRT and MFC vNext (11) cannot be used on Windows XP SP3 by Mike

Closed
as By Design Help for as By Design

138
15
Sign in
 to vote
Type: Bug
ID: 690617
Opened: 9/24/2011 4:38:35 AM
Access Restriction: Public
Moderator Decision: Sent to Engineering Team for consideration
2
Workaround(s)
13
User(s) can reproduce this bug
Any app that you create with Visual C++ vNext cannot be used on a widely used operating system, Windows XP. This effectively prevents its use for any serious work.
Details (expand)

Visual Studio/Silverlight/Tooling version

Visual Studio v-Next

What category (if any) best represents this feedback?

Compatibility

Steps to reproduce

1) Create a Wizard generated Win32 app or MFC app
2) Build a release version
3) Copy the release executable and msvcr110.dll (and mfc110.dll if an MFC app) along with it to a Windows XP SP3 machine.
4) Attempt to view it using dependency walker. Notice several red icons, denoting function calls made from the CRT and MFC that are APIs that are only available from Vista and above. Also notice that the application and DLLs have been marked with linker and subsystem version 6.0 (instead of 5.1), thereby sealing their fates (this could be changed via link time options for the app but obviously not the prebuilt DLLs)

Product Language

English

Operating System

Windows XP

Operating System Language

English

Actual results

application does not run successfully under XP

Expected results

application should run fine under XP
File Attachments
0 attachments
Sign in to post a comment.
Posted by Zaslow at Flexi on 2/22/2012 at 10:03 AM
I think that what I want to say has already been said by others. I just wanted to leave a written response to highlight that this is a significant problem for our company.

Like others this restriction will force us to stay with VS 2010 because of the needs of our customer base. I was looking forward to some of the additional C++ features that are part of vNext (CLI Intellisense, C++ 11 features, etc.).

If what was said about the changes that you'd have to make to support XP being minor are true it is a shame that so many of us would miss out due to such an easily remedied problem. I think that the least that you could do would be to explain why you are choosing not to support XP.
Posted by Anna-Jayne Metcalfe on 2/10/2012 at 9:52 AM
Like many vendors, we have absolutely no control over the OSs our customers used, so until the market share of XP among our customer base drops to a negligible level there is absolutely no way we can consider dropping support for it.

The main attraction for us in VS11 is the (more C++ 11 compliant) compiler and standard library, but we're not about to adopt it if it means leaving our customers out in the cold...it would quite simply be commercial suicide to do so.

Hence we cannot adopt VS11 (or its successors, for that matter) until the market share of XP among our customer base drops to a negligible level or the daft decision to drop runtime support for XP is reversed.
Posted by xpclient on 2/3/2012 at 11:03 PM
Please support Windows XP for at least runtime, if not design time or else I won't buy VS 11. You can't force us to drop our XP customers even if you don't support your own products on Windows XP.
Posted by johnwbyrd on 2/2/2012 at 11:50 AM
This is not a sane decision. Any real-world app developer, armed with this information, will pin their development tools to Visual Studio 2010 for the next five to ten years at least.

We can't afford to alienate our customers by breaking our product on XP. So we'll be skipping 2011 until Microsoft figures this one out.
Posted by Diego Vallone on 1/25/2012 at 9:27 PM
What about those of us that develop for Windows Embedded Standard 2009 (which essentially is a XP SP3), a product which lifecycle ends on 1/8/2019 ??
Seven years of oblivion?

Please Team, reconsider this. Please...
Posted by Mike on 1/23/2012 at 1:44 PM
One big thing that works against us having any sort of nice workaround for this, is the fact that as of Visual C++ 2010, the CRT and MFC rebuild makefiles are no longer included with the source code. In 2008 and earlier, it was so easy to rebuild CRT and MFC DLLs because there was a clear set of makefiles included. Now all there is, is a silly "these are the compiler and linker switches we use, go find your own solution to rebuild these" web page. So as a compromise, keep the source the same, but re-introduce the ability to rebuild the CRT and MFC by providing the MSbuild/VCbuild/makefiles what ever they may currently be.
Posted by AshleysBrain on 1/12/2012 at 9:20 AM
There would be absolute mutiny with our customers if we dropped XP support. We can't even consider this until XP is ignorable. By the looks of things by the time XP is ignorable, another version of Visual Studio will be out! So it seems a strange decision for you to make, Microsoft, since the solution is just to skip buying vNext and buy vNext + 1, when we would have bought both if you kept XP support in vNext!
Posted by Paul Grunau on 1/2/2012 at 9:39 AM
Microsoft's official end-of-life date for XP is irrelevant - what matters to developers shipping software is the size of the installed base, and the rate at which it's shrinking. This graph indicates that XP's current installed base is 34% of all OS's (as of January 2012).
http://gs.statcounter.com/#os-ww-monthly-201001-201201

What's interesting is that while it's 34% now, a year ago it was 49% and a year before that it was 63%. So it's share has been dropping at a consistent rate - a straight linear projection means XP share will be 19% in Jan 2013 and about 5% in Jan 2014 (though this number will likely be higher, since the projection line will flatten as it approaches 0).

My conclusion from this is that any software shipping in 2012 needs to support XP, and the real transition year will be in 2013, where new software can start to drop XP support. After January 2014, there will likely be little reason to support XP in new software releases.

If Microsoft wants developers to start using VS.Next in 2012 for native development, they need to support XP targeting with CRT and MFC. If they maintain their current stance to not do this, then I think it's best to just ignore VS.Next until sometime in 2013.
Posted by Merich10 on 12/29/2011 at 12:12 PM
Yet another decision that puts Microsoft's desires above the needs of their customers and developers.

This guarantees that a good percentage of us won't be able to use vNext in any capacity.
Posted by unsalted-pretzel on 12/28/2011 at 2:52 PM
What is the cost to Microsoft for funding someone to add the #ifdef's in the CRT to target XP v.s. the (unseen) cost on all the rest of us? (I have recollections of spending some time myself to hack the VS EXE output to run on Win2000.)

Using another compiler just to target XP also has a cost. I've been doing some work with the Intel C++ compiler, which has plugins for VS, and maybe this is something to consider in the future. I also know projects that stay with mingw due to the (different) headache of CRT binary incompatibility for DLL's compiled between VS versions -- described in http://msdn.microsoft.com/en-us/library/ms235460.aspx ; http://planet.jboss.org/view/post.seam;jsessionid=7DAEE574F8150631850C69069245BBB2?post=fighting_the_msvcrt_dll_hell .

Yes, Win7 is where it's at for most users wanting a secure desktop connected to the Internet, but certain applications that are more isolated from external security concerns will still be using XP beyond its EOL (e.g. instrument control or virtual machines hosting non-Internet facing applications).
Posted by Demented Devil on 12/27/2011 at 9:43 PM
Stopping compiler support a full two years prior to the end-of-support date is really not cool
By all means restrict the developer environment to a minimum of Windows Vista if you wish but limiting the runtime support goes against the pail - like many others here I too have many customers still running Windows XP systems.

Please, please, please reconsider this decision
Posted by Aidtopia on 12/12/2011 at 10:20 AM
Windows XP is supported until April 2014[1,2], so it seems a bit premature to deprecate support for Windows XP in the compiler and related tools.

[1]: http://windows.microsoft.com/en-US/windows/help/end-support
[2]: http://www.microsoft.com/en-us/windows/endofsupport.aspx
Posted by thatsalok on 12/8/2011 at 6:04 AM
Agree with all of developer who are supporting inclusion of window XP here. Take my case, my application customer base consist of mainly of WindowXP. I can't expect all of my client to update, because I am updating my source code for latest version of Visual Studio.

they are happy with what they have. i would like to request MS to please reconsider there decision


Posted by Örjano Stefano Garage on 12/6/2011 at 11:04 AM
I'll add my voice to the chorus asking you to support XP in vNext.
Posted by tkc5443 on 12/6/2011 at 5:03 AM
This is very bad. Other Microsoft teams always try to go the extra mile wrt compatibility with previous versions of Microsoft products, so dropping compatibility of the CRT (!) with Windows XP (!) is unthinkable!

Windows XP is at the moment the most used version of Windows. By the time VC11 is issued it might be the second most used version of Windows, but that's it. It will still be used by 20% - 25% systems, conservatively. We, the C++ developers writing for Windows simply can not afford losing this audience.

This is a huge blunder. Microsoft, please reconsider. Please use the functionality that doesn't exist in Windows XP via LoadLibrary. We are doing this in our code, why can't you?
Posted by small_mountain_0705 on 12/1/2011 at 10:42 AM
I'm with Microsoft on this one. XP users can use previous versions of my product that supported XP. If you want the latest version, it's time to move forward. I want the Windows dev tools to be optimized for current versions of the operating system and not have Microsoft have to continue to expend resources testing on XP. Vista, Win7 and Win8 are enough versions for Microsoft to continue supporting.
Posted by Martin Ba. _ on 11/30/2011 at 10:57 PM
Interesting decision on MSs part. It simply means *we will not buy Visual Studio 11* (or, well, probably v12 and v13 as well). Maybe, just maybe, by the time v14 comes out, we won't have to support Windows XP anymore.
It's just lost revenue for Microsoft. (And a tad annoying for us, but maybe I'll learn to live with VS10.)
Posted by Phil Barila on 11/28/2011 at 9:13 AM
I'll add my voice to the chorus asking you to support XP in vNext. Your (and our) customers haven't put that OS out to pasture yet, no matter how badly you want them to. Love to move beyond XP/Server 2003 generation, customers haven't gone there yet.
Posted by Mihai Maerean on 11/18/2011 at 12:36 PM
why wouldn't a C++ RunTime and MFC library work on Windows XP?
it makes no sense (other than MS's stupid marketing, i.e. screw the customers and their needs that they pay for to have them fulfilled)
Posted by JohanRade on 11/16/2011 at 9:43 AM
According to

http://www.w3schools.com/browsers/browsers_os.asp
http://gs.statcounter.com/#os-ww-monthly-201010-201110

Windows XP still has about 1/3 of the operating system market.
So dropping support for XP is madness.

The workaround described on this page

"the native multi-targeting feature, which requires you to have both vNext and 2010 (licensed) installed on the machine, will allow you to build XP apps from vNext, but not use the new libraries, compilers, and headers."

just does not make any sense. What is the point of upgrading if you can "not use the new libraries, compilers, and headers"?


Posted by RAB36 on 11/16/2011 at 1:06 AM
I cannot believe this. If this is really true, this is by far the biggest disappointment with VS vNext so far. There is no point in even looking into the new features when we cannot produce programs for Windows XP any mor.

There is a huge number of machines world wide running still Windows XP and I absolutely cannot understand how Microsoft can think, that we can afford not supporting all those customers any more.

Best regards,
Bernd
Posted by JohanRade on 11/15/2011 at 10:28 AM
Many of our customers still use XP. If Visual Studio 11 can not build C++ applications that run on XP, then we will not be able to upgrade.
Posted by Unque on 11/13/2011 at 2:09 AM
But Most of users in the world uses Windows xp. If VC++ 11 not supported We can't make commercial applications for Most of user. Please Reconsider this again.
Posted by David Webber on 11/6/2011 at 8:29 AM
Some of us still have an active client base using XP. If MFC11 does not run on XP, this will make it impossible to use it commercially for quite some time to come. Please reconsider!
Posted by Steven Bone on 10/21/2011 at 5:08 AM
Please reconsider your position on this 'design' choice. I personally have not checked VS11 runtime issues against Windows Embedded, but it is based on XP SP3, and I believe the support lifecycle on that is another 8 or so years for that OS.

I had to support code running on NT4 up until just a few years ago (sort of embedded systems), and the C++ runtime is certainly NOT where I would expect to have issues with compatibility.
Posted by Mike on 10/13/2011 at 11:14 AM
Looking at the internals of the implementation of the CRT and MFC (source code provided by vNext public release), I hazard a guess that there is no turning back now. There are fundamental changes to the CRT, such as using locale name instead of locale ID, and calling Vista only functions such as GetTickCount64, that I can no longer imagine that there will ever be a vNext version of the CRT that supports XP SP3. It's time for me to start work on making other workarounds (at least for the statically linked CRT so it can function on XP).
Posted by GregM on 10/9/2011 at 3:53 PM
XP SP3 is still a supported operating system, so support it.
Posted by GP Smith on 10/4/2011 at 7:07 AM
Although, in a perfect world, all our customers would upgrade to the latest and greatest OS, we provide products for users in the academic community and we have to support what they actually run. Windows XP is still a major system in use by our customers. We will not be able to use vNext if it does not support all the OS that our customers use.
Posted by JohnCz on 9/29/2011 at 8:26 AM
I wholeheartedly second Mike's suggestion to reexamine this decision.
Posted by Mike on 9/26/2011 at 11:59 AM
Thanks, Pat. I suspected as such. It's my hope that anyone that sees this bug item will express their vote in favor of reexamining this decision sometime before release of Beta 1.
Posted by Microsoft on 9/26/2011 at 10:34 AM
Hello Mike,

Thanks for the report. This behavior is by design in MFC and CRT for Visual Studio vNext. The minimum supported operating systems are Windows Server 2008 SP2 and Windows Vista. Windows XP is not a supported operating system for the release (design-time or run-time).

Pat Brenner
Visual C++ Libraries Development
Posted by MS-Moderator07 [Feedback Moderator] on 9/25/2011 at 7:05 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Posted by MS-Moderator07 [Feedback Moderator] on 9/25/2011 at 7:05 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Posted by MS-Moderator01 on 9/24/2011 at 4:43 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by Mike on 9/27/2011 at 4:17 AM
the native multi-targeting feature, which requires you to have both vNext and 2010 (licensed) installed on the machine, will allow you to build XP apps from vNext, but not use the new libraries, compilers, and headers.
Posted by Mike on 11/24/2011 at 8:33 PM
I've been informed you can use the free Windows 7 SDK 7.1 (as an alternative to VC2010) with vNext and native multi-targeting, but of course the limitation of not getting to use the new libraries, compilers, and headers still exists, meaning you can't take advantage of any of the new features of vNext (except IDE features of course)
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement