close
The Wayback Machine - https://web.archive.org/web/20111216195941/https://connect.microsoft.com/VisualStudio/feedback/details/690617
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

91
13
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)
5
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 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)
© 2011 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement