Tech Off Thread

74 posts

Conversation Locked

This conversation has been locked by the site admins. No new comments can be made.

A question on XP support in VC11

Back to Forum: Tech Off
  • User profile image
    evildictait​or

    , spivonious wrote

    ... but a lot of businesses are sticking with XP because there are no compelling reasons to upgrade. 

    It only gets harder to upgrade the longer you leave it. And given the almost daily news coverage of companies getting hacked and losing vast reputation, customer-base, IPR and getting sued for data-protection violations, I'd have thought security alone is still a pretty good reason to upgrade.

    Word, Excel, and homegrown VB6 apps don't benefit at all from a move to 64-bit.

    As much as I'd love to be running the latest and greatest, there really is no business case for the upgrade. What I would like is to be able to develop in VS11, but I guess that's not going to happen.

    So you're saying if Microsoft provided VS11 for XP then your company would spite Microsoft by sticking with XP for longer and not giving Microsoft money to upgrade to Vista or later? I'm really not seeing the business case here for Microsoft to go out of its way to give you reasons to not buy their core product.

  • User profile image
    AndyC

    , spivonious wrote

    *snip*

    Word, Excel, and homegrown VB6 apps don't benefit at all from a move to 64-bit.

    As much as I'd love to be running the latest and greatest, there really is no business case for the upgrade. What I would like is to be able to develop in VS11, but I guess that's not going to happen.

    If you don't accept security as a business case (and you probably should), then the only driving factor is likely to be app compatibility. So VS11 not running on XP is merely the first in a line of reasons to upgrade.

    And if you're running a VDI infrastructure already, you're actually in a much better position to handle upgrading in a rather more seamless fashion.

  • User profile image
    cheong

    , spivonious wrote

    Word, Excel, and homegrown VB6 apps don't benefit at all from a move to 64-bit.

    Not exactly. Any 32-bit applications can get full 32-bit range of address space in 64-bit environment, if the machine have more than enough RAM (It's not that they can't have that in 32-bit machine, but some of the memory content will be on disk then, and this could mean a performance hit).

    This fact can be useful for applications made with out-of-proc COM+ components.

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    evildictait​or

    , cheong wrote

    *snip*

    Not exactly. Any 32-bit applications can get full 32-bit range of address space in 64-bit environment, if the machine have more than enough RAM (It's not that they can't have that in 32-bit machine, but some of the memory content will be on disk then, and this could mean a performance hit).

    This fact can be useful for applications made with out-of-proc COM+ components.

    That fact is even more useful to in-proc COM objects. 32-bit apps also have a 32-bit heap, which means even if you're using a scripting language like VB, you're still constrained to using less than 3GB of total memory in the address space, whether those objects are VB variants or not. If you're 64-bit you can have more VB variants in your address space.

  • User profile image
    Ted.w

    quick status update:

    over 1000 votes at the uservoice site:

    http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2287078-allow-mfc-11-to-run-in-xp-sp3

    over 200 on the connect site:

    http://connect.microsoft.com/VisualStudio/feedback/details/690617/

    still no mainstream media coverage:

    http://supportxp.com/2012/04/06/absence-of-media-coverage-regarding-the-lack-of-xp-support-in-vc11/

    static link workaround developed:

    http://tedwvc.wordpress.com/2012/03/11/how-to-get-visual-c-2012-vc-11-beta-statically-linked-crt-and-mfc-applications-to-run-on-windows-xp/

    All I can say right now is *please* keep up the pressure.  This is not the time to throw in the towel regarding XP support in VC11.  Anyone on the TAP program or some super-elite special relationships with Microsoft (e.g. 1000s of licenses of MSDN), now is the time to play your cards.  Contact Microsoft and make it clear to them that you are not going to touch this product for years to come. 

    A big thank you to the supporters so far!

  • User profile image
    evildictait​or

    It's not going to work. Windows XP is too old for the CRT to work - and what you are suggesting is that you want Microsoft's CRT both now and forever to permanantly live in 2002-land - and forego every new technology and invention since XP shipped in order to support old-and-crusty OSes that Microsoft isn't even supporting.

    If you want to write apps for XP, use VS2010. You don't need VS2011 even half as much as your customers need to upgrade. It's already going to be a pain for you to test (since VS2011 sure as hell won't run on XP either) - why not just put VS2005 on an XP machine and then you'd be able to press F5-and-test rather than having a pretty VS2011 on a completely different machine that you have to copy the binary to your XP machine to test anyway?

    If you really care that much, swap out the compiler by changing the build settings to use a VS2008 compiler or GCC and then you can use the VS2011 front-end and spit out binaries ready for even the crustiest machines. 

  • User profile image
    AndyC

    , Ted.w wrote

    Anyone on the TAP program or some super-elite special relationships with Microsoft (e.g. 1000s of licenses of MSDN), now is the time to play your cards.  Contact Microsoft and make it clear to them that you are not going to touch this product for years to come. 

    A big thank you to the supporters so far!

    I don't think you can be in the TAP program and still be running on XP, that would kind of defeat the point, wouldn't it?

    In any case, if you've only got 1000 people who actually care, I'd say you've pretty much confirmed that Microsoft are right not to worry about it.

  • User profile image
    MrChris

    evildictaitor, you're extremely arrogant and your logic is flawed. Your arguments are of no value, because most people know the exact reasons why the CRT does not run on XP. XP IS NOT TOO OLD.

    1. The new CRT uses only a handful of WinAPI functions that are available on Vista+. Those functions, however, do not provide any real benefits over the pre-Vista alternatives. It seems as if some manager just told the developers to randomly use a few newer functions that are not available on XP.

    2. The CRT can be made to run on XP. And it can still take advantages of the no-real-benefit functions when on Vista+ via GetProcAddress. Damn, you could even provide 2 CRTs if GetProcAddress is an issue (but it's not as the new CRT still uses it).

    3. Modifying the CRT to run on XP is a very simple process. If it takes a single Microsoft employee more than a few hours, then that person is just incompetent. But surely the reasons are the high managers making their weird decisions. I just hope no one comes up with a stupid "no resources" argument.

    4. Developers already run Windows 7, most likely. They don't care if VS11 runs on XP or not. However they do care if the executables created with VS11 run on XP, because a high percentage of the customers of those developers are still running XP.

    5. If VC++11 RTM generated executables (using the new toolsets!) won't run on XP, then developers just won't  buy VS11. There are alternatives, MinGW. At this point Microsoft can say bye bye to their plan of having the developers force their customers to upgrade.

    6. The speed of the upgrade process among regular users will not increase. However there will be no VS11 sales among C++ developers. So it's a lose-lose decision for Microsoft.

     

    Whoever at Microsoft thought that making VS11 generated executables not run on XP will bring them in more money, please go back to business school.

     

     

  • User profile image
    AndyC

    , MrChris wrote

    3. Modifying the CRT to run on XP is a very simple process. If it takes a single Microsoft employee more than a few hours, then that person is just incompetent. But surely the reasons are the high managers making their weird decisions. I just hope no one comes up with a stupid "no resources" argument. 

    Even if you modify the CRT so that it only uses calls available on XP, most of the Windows headers in the current SDK don't support XP, so you still couldn't use it without a massive amount of effort going into ensuring all the header files are compatible with XP.

    It isn't going to happen.

  • User profile image
    Piki

    AndyC, you clearly have no idea what you are talking about. There is no reason as to why the headers that worked with VS10 could not work with VS11. As demonstrated by the workarounds, ditching XP was not a technical decision. VS11 could support XP easily but Microsoft decided otherwise.

  • User profile image
    Piki

    evildicatator, how is Windows XP too old when the VS11 CRT can be modified to run on XP in an hour or two?

  • User profile image
    evildictait​or

    XP IS NOT TOO OLD.

    XP is pretty old - but more importantly it's outside of it's support-cycle (which ended in 2009). The CRT dropping support for EOLed OSes is not new:

    VS in 2012 dropped Windows XP which expired in 2009.

    VS in 2010 dropped Windows 2000 which expired the same year.

    VS in 2007 dropped Win98/ME and NT4, all three already expired.

    VS in 2005 dropped Win95 which had already expired.

    2. The CRT can be made to run on XP. And it can still take advantages of the no-real-benefit functions when on Vista+ via GetProcAddress. Damn, you could even provide 2 CRTs if GetProcAddress is an issue (but it's not as the new CRT still uses it).

    Using GetProcAddress and so on means that your CRT is now performing more conditionals and more indirected calls than would be the case if you just link directly. This slows the CRT down on all Windows XP, Vista, 7 and 8 machines just so Microsoft can support XP customers. It also makes it much harder to test (because it's fundamentally a more complex program now) and much more difficult to prove that it's correct with static analysis tools.

    Microsoft could support two CRTs as you say - a good one for Windows Vista+ and a rubbish one for XP, but congratulations - now Microsoft have to support a whole extra product, complete with security, perf, usability testing and application-compatibility testing. Sure making the change would take half a day to write in code. But you've just committed yourself to six man-months of extra testing. And anyway, loads of websites will come along telling developers who have problems in their application to use the "old CRT that just works", hence losing all of the benefits of the fast new CRT for no gain; essentially this path quickly regresses to a "don't use anything invented since 2001" argument.

    So Microsoft could only ever use features invented before 2001. That means you don't get any thin locks (so all heap allocations are slower), and you don't get any of the FLS functions which means the CRT can't ever use light-weight threads, or have to suffer memory leaks which slowly cause long running apps to fail.

    3. ... But surely the reasons are the high managers making their weird decisions. 

    Decisions in a product-team are made by the product-team, not by "high managers". This decision will have been made by the PM of the CRT based on the evidence of the technical people that work for him/her (who actually write the code).

    They will have made the decision that the number of lost customers of VS2011 due to dropping support for XP will be less than the cost of maintaining separate (or dual) CRTs - because those customers won't be upgrading sideways (going to Win7 from XP is easier than to Linux or OSX), VS2011 wasn't going to run on XP anyway, and devs that build on 7 for release on XP are few, and can either swap out the compiler, or can copy their solution over to a VS2005-XP build machine and compile it there.

  • User profile image
    MrChris

    AndyC, you don't make sense. The header files just give you the function prototypes, and these prototypes do not change.

     

    evildictaitor, Windows XP SP3 is supported until 2014. So this is in fact the first time VS drops an OS before it's support ends.

    GetProcAddress will not affect performance if used right. That's why the CRT initializes itself, it makes the decisions once instead of deciding on every function call. For example in the new CRT during the initialization of the threading library GetProcAddress is used to get the right functions (different for Vista, W7, W8). It then stores these functions in function pointers, the decision is made only once.

    You might think why the C++ guys complain about the new CRT not running on XP while .NET guys are quite silent about .NET 4.5 (which supposedly doesn't run on XP as well). That's because the .NET guys already have pretty much everything with .NET 4.0. The C++ standard was recently updated and it's a huge change, so much goodness. Not being able to use the new features is a disaster for us.

    If you're a Microsoft employee (which I think you are), suggest someone from the CRT team to post on Uservoice to clear things up about this situation.

  • User profile image
    evildictait​or

    , MrChris wrote

    evildictaitor, Windows XP SP3 is supported until 2014. So this is in fact the first time VS drops an OS before it's support ends.

    No it's not. That's extended support, which means Microsoft will still ship security updates for it, and for a few thousand dollars a year they'll give you a phone number where they'll tell you how to turn your computer on and off again.

    XP stopped being in mainstream support in 2009, so Microsoft product teams don't have to test their new products on it (so far as Microsoft is concerned, XP is dead). http://windows.microsoft.com/en-us/windows/products/lifecycle. Supporting XP isn't broken on purpose, but it's not actively tested against - and the first guy who imports a function that isn't there on XP will suddenly break support for XP.

    It's not Microsoft's job to support your customers being on operating systems that Microsoft doesn't support and doesn't want them to be on. That's why Microsoft won't let you compile your C++ into ELFs for Linux or Mac-os for Mac. Microsoft really doesn't want your customers to be on XP anymore - and it wants that much more than it want's you to buy a VS2011 licence, no offence.

    If you're a Microsoft employee (which I think you are), suggest someone from the CRT team to post on Uservoice to clear things up about this situation.

    According to Microsoft connect (http://connect.microsoft.com/VisualStudio/feedback/details/730731/crt-and-mfc-in-vc-11-dont-support-windows-xp-sp3):

    Hello,

    Thanks for your feedback. The official position for VS11 Beta support for XP has been listed at the following uservoice post:
    http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2287078-allow-mfc-11-to-run-in-xp-sp3

    The team is aware of the concerns created by this decision. However, as of now we are not in a position to comment on fixing this.

    Thank you,
    Visual C++ Team

    Amusingly the first comment refers to my comments on this thread, but I think the C++ team are referring to this post:

    Visual Studio 11 Beta does not support targeting the Windows XP platform. As a result the C++ runtime libraries (CRT, MFC etc.) that come with it will also not run on Windows XP. If you already have Visual Studio 2010 and use it to build solutions that target Windows XP, then you can still install Visual Studio 11 Beta and continue to use the tool-chain (compilers and libraries) from Visual Studio 2010. This will allow you to target Windows XP while still taking advantage of the new productivity features in Visual Studio 11 Beta

    ...

    Win32 API in Vista+ are now included in Dev11 CRT, mainly to make use of some newer functionality.

    Also, In Dev11 we've changed our internal logic for locale supporting and locale-sensitive functions (such as setlocale, printf, atoi, ..) to use locale names instead of the old LCID. XP doesn't have APIs supporting locale names.

    Another reason for using some newer API (not present in XP) is the use of One Time initialization APIs for lazy initialization, which provides some memory savings for the CRT. 

    (Raman Sharma)

    So there you go. It's official.

  • User profile image
    Piki

    @evildictaitor: According to Herb Sutter "VC11 [RTM] might or might not ship with XP targeting support, but as of right now that's an open question". So the final decision has not been made yet (or Herb is lying).

    http://herbsutter.com/2012/02/29/vc11-beta-on-feb-29#comment-4887

     

  • User profile image
    blowdart

    , evildictaitor wrote

     

    So there you go. It's official.

    And apparently you're an MS employee Big Smile

     

  • User profile image
    phil7

    Unfortunately in most cases the providers of enterprise software are not the ones which decide whether a (end-)customer does upgrade from Windows XP to Win7 or not.

    If you (as a software provider) drop Windows XP support for your product and your competitor does not, you've got a problem.

    So I think that the direction of forcing the upgrade from WinXP to a new OS is wrong.
    It should go via end-customers (enterprise users of Windows XP) to the developers and NOT the other way around.
    Not the developer of enterprise software should tell the end-customer to upgrade - Microsoft should do it (or force it).

    Just my 2 cents ...

  • User profile image
    evildictait​or

    ...

    I think we're getting a bit confused here. Upgrading your dev-tools necessarily involves pain - if you're moving sideways you'll find that #pragmas and funky syntax like __forceinline stop working, if you move backwards you'll find that new syntax stops working and if you move forwards you'll find old backends being unsupported.

    It's all a trade-off.

    If you need to write programs for XP, stick with what you've got or move sideways - or use an open-source CRT or a VS2010 backend if you really want the VS2011 IDE.

    If, as I suspect, you have some XP users, then you need to weigh up the productivity gain of using VS2011 (i.e. the money you'll save by being more effective) versus the loss of business from XP customers (i.e. the money you'll lose by losing customers).

    If money out is more than money in, stick with what you've got for the time-being. Enterprise customers on XP are living on borrowed time and will slowly upgrade out of XP or they'll be left behind by your competitors as well.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.