It would be great to get a technical answer from someone on this. Even if its not feasible to continue XP support at least armed with the reason for dropping it people can make informed decisions about how to move forward.

----

10 hours ago, rab36 wrote

*snip*

Windows XP extended support lasts until April 9th, 2014. VS 11 is supposed to be released in 2012, right? So why not supporting to create C++ programs for XP in VS 11 with the latest C++ toolset?

.NET 4.5 will very probably support Windows XP because it is an inplace upgrade from 4.0: http://reddevnews.com/blogs/rdn-express/2011/11/back-to-app-migrations-with-ms-net-vnext.aspx

So why not offer C++ programmers the same possibilities?

What is the motivation? What are the technical reasons, if there are any?

I just want to elaborate a bit more about our motivation to support XP at least until 2014, maybe even longer with our software:

We are a manufacturer of measurement systems that are sold with an industrial PC (with Windows XP or Windows 7) and a sophisticated C++ application for acquiring, storing, analyzing the data.

Only recently we managed to offer Windows 7 64-Bit with all our systems because of driver issues of 3^rd party data acquisition boards that are in the IPC.

We have an OEM license agreement with Microsoft for embedded systems that still allows us to purchase Windows XP.

We are selling maintenance agreements with our software and we have lots of systems on maintenance worldwide that are running Windows XP. Some of them are used in test lab or production environments that are not even connected to a network, so even the end of extended support of Windows XP in April 2014 will not force customers to migrate to Win 7. Upgrades to Windows 7 are difficult and expensive because hardware (because of the driver incompatibilities) with costs of several thousand of dollars (up to $15.000) has to be exchanged. The measurement hardware of the system is used typically for longer than 10 years, the IPCs are exchanged every 5-7 years.

On the other hand, I am very interested in using the latest Visual Studio and toolset for our software. In the past, we managed to migrate to the latest Visual Studio release typically within one year after the release of Visual Studio. We have a demanding application that makes heavy use of multitasking and multithreading. New features are developed with the latest language features and libraries. We are using lambdas, auto, PPL and ConCRT and agents library right now with VS 2010 SP1 in our product.

Not being able to use the latest toolset lets say in 2013 (because of Windows XP) would heavily impact this strategy. I expect that we have to support XP until at least 2015. So having no XP support in VS 11 comes way to early for us.

Bernd

VS / VC is targeting the "Platform" that Microsoft sells.  Microsoft is not selling XP any longer and is asking folks to follow the guidelines and policy that they have published.

with the release of windows 8  xp will be 4 versions back. it has reached the end of support and sales.  and for the small number of developers who still must support XP they can use VS 2010 or VS 2008 to do that.

that aside I personally would say that it's time to get the apps to WIndows 7 at least and stop using the XP OS for many many reasons.

a company that is using multiple vendors to make a system or device should make sure they are not shooting thier own foot.  they should have known that xp is end of life  and started the update / migration long before this happened. if they failed to read the published notices and makie the right plans that is not Microsofts fault.

2 hours ago, spivonious wrote

A somewhat related question...what's VB6 support like on Windows 7? I'd say 90% of our apps are written in VB6 and migrating them to .NET would be a huge effort.

in general normal stuff should work.  really you need to just start testing the apps and find out.

heck there are a lot of things that a "vb6 app" might do that could be an issue and you have to know what the app does.

for example: trying to write files in folders that apps are not supposed to use.  in say windows 95 or windows 2000 the app generally worked .... but in vista or 7 the same app would have issues.

vista will be more in-your-face about it.  in fact i would even say test the app with vista ...

if it works there then 7 should be fine.

if vista complains see if it can be updated to fix it.

if not you have two options: 

1)  application compatibility settings

2)  xp Mode - the virtual pc running xp that is a free part of windows 7.

app compat settings:  as i recall there is a tool from MS to help with creating a profile to run the app on the new os with some settings to "smooth over" some issues.

if all else fails XP Mode can run a lot of old stuff and to the user it looks like they are not even using a virtual machine other than the "window chrome" is the XP style.

Most of the major PC manufacturers have had 2012 as the last year they expected to produce XP-compatible hardware for several years now, I don't see that changing either. As with every release of Windows, attempting to continue using it right to the end of it's product lifecycle becomes an expensive and inconvenient option, the world moves on and it's best to strategically plan not to end up in that situation.

3 hours ago, figuerres wrote

*snip*

in general normal stuff should work.  really you need to just start testing the apps and find out.

heck there are a lot of things that a "vb6 app" might do that could be an issue and you have to know what the app does.

for example: trying to write files in folders that apps are not supposed to use.  in say windows 95 or windows 2000 the app generally worked .... but in vista or 7 the same app would have issues.

vista will be more in-your-face about it.  in fact i would even say test the app with vista ...

if it works there then 7 should be fine.

if vista complains see if it can be updated to fix it.

if not you have two options: 

1)  application compatibility settings

2)  xp Mode - the virtual pc running xp that is a free part of windows 7.

 

app compat settings:  as i recall there is a tool from MS to help with creating a profile to run the app on the new os with some settings to "smooth over" some issues.

if all else fails XP Mode can run a lot of old stuff and to the user it looks like they are not even using a virtual machine other than the "window chrome" is the XP style.

That's good to hear. Generally, we should be fine as most apps don't write files. Some do make reads/writes to HKLM, which I assume will need UAC elevation.

38 minutes ago, spivonious wrote

*snip*

That's good to hear. Generally, we should be fine as most apps don't write files. Some do make reads/writes to HKLM, which I assume will need UAC elevation.

Possibly not, depending upon how important it is that it's in HKLM. Given that VB6 won't manifest executables as Vista+ compatible, they'll get File and Registry Virtualisation applied to them and thus writes to HKLM will be "faked" into HKCU so that only that app will see the change.

15 hours ago, AndyC wrote

Just because XP is "supported" by the Windows team (even if in a security-fix only state), it doesn't follow that the developer division should necessarily continue to produce newer tools for it, it is fundamentally a dead platform, the tools needed already exist and nothing is going to change that.

* We don't have to support Windows XP because it's end-of-lifed

* Supporting Windows XP is expensive (since we have to test it on more platforms than if we didn't)

* Supporting Windows XP can reduce the performance of our main product (since conditional execution to do one thing on XP and another on new OSes is slower and testing on Windows XP editions is time that could be spent making improvements on Windows 7 editions)

* Supporting newer versions of Windows means we can use newer features (such as slim-read-write locks or NTFS transactions) without having to have crusty code for implementing that functionality on older OSes which don't have them built in.

* There are tools already out there to build executables for XP - so we're not even constraining our customers by stopping Windows XP support in Visual Studio

* If this helps to nudge our customers, or customers of customers to upgrade to a newer version of Windows, we get more money.

So remind me again why Microsoft would want to ship a product that supports Windows XP?

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.                                       

I suggest you vote on the issue (both pro and con) at both:

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

and

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

Ted.

35 minutes ago, Ted.w wrote

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.                                       

If you want to play chicken with the Microsoft product cycle, you're going to lose.

No offence, but the number of developers dev-ing for Windows XP is such a tiny drop in the ocean compared with Win7 developers that Microsoft would prefer to make VS2012 more awesome for Win7 developers than spend time supporting it on WinXP.

As for Windows Embedded, it's a whole different kettle of fish. It has a long support lifecycle because appliances are developed, shipped and then sat out in the wild for a long time before they're replaced. As such they aren't generally subject to the same kind of continous maintenance and app upgrades that a normal application would be.

In the end, it was found that the user is using a PC bought in 2003, and the display card on it only supports DX7.

Okay, perheps that means game developers should hold all the game development targeting DX10/11 and keep writing games only for DX7 now then...

20 hours ago, evildictaitor wrote

*snip*

If you want to play chicken with the Microsoft product cycle, you're going to lose.

No offence, but the number of developers dev-ing for Windows XP is such a tiny drop in the ocean compared with Win7 developers that Microsoft would prefer to make VS2012 more awesome for Win7 developers than spend time supporting it on WinXP.

Is it? I thought a majority of businesses were still on XP. I know we still are, and I have a hard time finding reasons to upgrade. As long as OEMs still make XP device drivers, we'll be on XP (much to my dismay).

3 hours ago, spivonious wrote

Is it? I thought a majority of businesses were still on XP. I know we still are, and I have a hard time finding reasons to upgrade.

I hate these "mini-factlets" that people keep repeating. Just because something used to be true doesn't mean it still is true, no matter how convenient the factlet happens to be.

Windows 7 is the biggest user-desktop and has been for several months now. http://www.ubergizmo.com/2011/10/windows-7-surpasses-windows-xps-market-share/

Ps, if you want a good reason to upgrade, I still think ASLR (http://en.wikipedia.org/wiki/Address_space_layout_randomization) is my favourite (and least well known one). It massively improves the security of your entire system, from the kernel, to the browser, to every app you choose to run on it - and is the reason why almost every single publically released exploit is either a logic-flaw or is targeted at Windows XP.

6 hours ago, spivonious wrote

*snip*

As long as OEMs still make XP device drivers, we'll be on XP (much to my dismay).

Last time I was involved in PC purchase contract negotiations, pretty much all the OEMs involved had 2012 as the last year they expected to still provide any XP drivers at all and that was only on low-end, long-term compatibility focused models. It's already quite easy to buy hardware that you'll never find XP drivers for.

5 days ago, evildictaitor wrote

*snip*

I hate these "mini-factlets" that people keep repeating. Just because something used to be true doesn't mean it still is true, no matter how convenient the factlet happens to be.

Windows 7 is the biggest user-desktop and has been for several months now. http://www.ubergizmo.com/2011/10/windows-7-surpasses-windows-xps-market-share/

Ps, if you want a good reason to upgrade, I still think ASLR (http://en.wikipedia.org/wiki/Address_space_layout_randomization) is my favourite (and least well known one). It massively improves the security of your entire system, from the kernel, to the browser, to every app you choose to run on it - and is the reason why almost every single publically released exploit is either a logic-flaw or is targeted at Windows XP.

But that's total market share. I believe that a large majority of consumers have upgraded or purchased new PCs, but a lot of businesses are sticking with XP because there are no compelling reasons to upgrade. Security is better, but our users are locked down and get a fresh VM every login (thin clients connecting to VMware VDI). Thin clients also remove the reliance on driver support.

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.

1 hour ago, 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.

1 hour ago, 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.

6 hours ago, 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.

7 hours ago, 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.

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!

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. 

1 day ago, 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.

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.

3 hours ago, 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.

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.

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.

52 minutes ago, 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.

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

7 hours ago, evildictaitor wrote

 

So there you go. It's official.

And apparently you're an MS employee

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 ...

...

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.

You quoted Raman Sharma's post. The new locale API can be simulated with the old one on XP. And no one has any idea what he's on about when he mentions the one-time-initialization APIs, the new CRT uses nothing like that.

Also, those few Microsoft employees who have commented on the situation have never used the "mainstream support for XP ended in 2009" argument. They have always referred to 2014 and tried to convince us that waiting 2 years for XP to be officially dead is not a long time. Well, 2 years is a long time.

1 hour ago, MrChris wrote

evildictaitor, the thing is that the CRT not supporting Windows XP SP3 is not justified, ... can be substituted ... without any performance penalties.

Just stating things doesn't make them true. You don't work for Microsoft's VS team and therefore don't have any idea of the decisions that were taken or the reasons that were given. You're just blindly stating that it's easy.

If building a CRT is so easy, don't link against the Microsoft CRT and build your own. That'll allow you to use the VS2011 IDE with no compatibility problems on XP. That way when it goes wrong or is slow, it'll be your responsibility to sort out and Microsoft won't have to slip the release of VS2011 in order to test the CRT on XP, and everyone will be happy.

My point about XP mainstream support isn't that Microsoft are deliberately breaking support for XP, just that they are not required to support XP anymore. Consequently an argument that "Oh you must support XP because my customers use it" doesn't hold any water at Microsoft.

If you want to argue for XP support in the CRT, I would avoid using the "it's cheap and easy" or "you have to" style arguments. If it was cheap and easy they'd have done it. And they don't have to because XP is out of mainstream support.

I'm glad there haven't been any official responses like "do it yourself if you want it so much", "do it yourself if you think it's so easy", that would literally be considered as spitting in the customer's face. In fact making the CRT run on XP is easy. I don't see why it would be any harder for the VS team than it has been for multiple people who have done it themselves as a proof-of-concept.

In one of your previous posts you said that Microsoft cares a lot more about the end user upgrading to a newer OS than the developer buying a VS licence. That's quite obvious. Let's consider that developers won't buy VS11 if they have a large Windows XP userbase. Could you describe a scenario where VC++11 not supporting XP as a target platform will lead to a more rapid upgrade process among XP users?

NOTE: I'm already trying to see this situation from Microsoft's viewpoint. I find it difficult to understand how such decision will benefit them in any way.

5 hours ago, Ted.w wrote

One thing I just noticed in their favor was in Raman's post, he mentioned the use of One Time Initialization APIs (e.g. InitOnceExecuteOnce).

Its been there since Vista.

4 hours ago, MrChris wrote

evildictaitor, you make it sound as if the customer is the enemy of Microsoft. Of course, Microsoft doesn't have they do anything if they don't want to. They might as well pack their bags and stop developing their products, who's there to judge them. But they want to gain profit. Isn't business about selling your product and satisfying the customer?

You make it sound like Microsoft only has one customer and that customer wants XP support as a backend to Visual Studio. That's not true. Microsoft has bajillions of customers for Visual Studio. All of them want a CRT that is faster, safer and cheaper. Not all of them want XP support as a backend. This means Microsoft is making trade-offs between spending effort making the CRT faster/better/stronger/etc versus adding new backends.

VS2011 is (compared with VS2010) having to support C++11, .NET4.5, ARM for user-mode applications for Win8 and support for Metro.

You might see supporting XP as the only key feature that you'd like in VS2011, but in real life it's pretty low on VS2011's priority list.

I'm glad there haven't been any official responses like "do it yourself if you want it so much", "do it yourself if you think it's so easy", that would literally be considered as spitting in the customer's face. In fact making the CRT run on XP is easy.

That is why nothing I post is an official response. If Charles or blowdart posted what I say here they'd cause an uproar. That's why I keep my non/employment at Microsoft deliberately ambiguous so you can't turn my rantings into a news-story.

In fact making the CRT run on XP is easy.

Again with just saying things. You have no idea how hard it is to make a CRT for XP, you're just assuming that it's easy because it helps your point to make Microsoft sound incompetent. If it's so easy to write your own CRT, just do it yourself. If it's too hard to just do yourself, perhaps it's not so easy for the VS2011 team either.

I don't see why it would be any harder for the VS team than it has been for multiple people who have done it themselves as a proof-of-concept.

What proofs of concept? Also a proof-of-concept is not a fully tested supported product sold for thousands of dollars to millions of customers who need 24/7 support when things go wrong, and where security problems can affect billions of computers.

Could you describe a scenario where VC++11 not supporting XP as a target platform will lead to a more rapid upgrade process among XP users?

I'm pretty sure that this isn't the reason that Microsoft are dropping support for XP, because I don't think they have a sufficiently coherent (or evil) strategy afoot, but the scenario exists anyway:

You're still in the mind-set of "I am a tiny little company, I have no sway over big companies - my competitors will take the market share that I lose".

From evil-Microsoft's perspective "You are one of many thousands of little companies. You and your competitors will eventually upgrade to VS2011, and the company will be unable to purchase either. If they want a new program they will be compelled to upgrade or resort to ever increasingly dirty hacks to keep their company chugging along. In practise this cost will force them to upgrade".

30 minutes ago, evildictaitor wrote

*snip*

You make it sound like Microsoft only has one customer and that customer wants XP support as a backend to Visual Studio. That's not true. Microsoft has bajillions of customers for Visual Studio. All of them want a CRT that is faster, safer and cheaper. Not all of them want XP support as a backend.

*snip*

With XP having a market share of 38%-48% *) I think it's fair to expect that most customers are still interested in XP support.

*) Source: Various random reports found via https://www.google.com/#q=xp+market+share+2012

57 minutes ago, deiruch wrote

With XP having a market share of 38%-48% *) I think it's fair to expect that most customers are still interested in XP support.

Those customers will find that Microsoft products are not working for them anymore.

Office 2010 does not work on XP.

IE8, never mind IE9 and IE10 does not work on XP.

Visual Studio 2010 does not work on XP

All of Microsoft's games division do not produce games that work on XP

Microsoft Hyper-V does not work on XP.

Do you see a pattern?

Microsoft director Stella Chemayk:

 "If you still have some PCs running Windows XP and Office 2003 in your organization," Microsoft director Stella Chernyak wrote in a post to the Windows For Your Business Blog, "now would be a good time to start migrating them to Windows 7 and Office 2010."

So Microsoft's official policy is "upgrade your XP". Not "let's find more excuses for customers to avoid upgrading from XP".

A typical business takes between 9 and 18 months to upgrade all of its machines to a new OS. This means that by the time VS2011 ships, either all of your customers will be running Vista+, will be in the process of upgrading, or will have resigned themselves to running an OS that simply isn't suited to modern day use and which Microsoft will have well-and-truly left on the scrap pile.

7 hours ago, evildictaitor wrote

*snip*

Those customers will find that Microsoft products are not working for them anymore.

Visual Studio 2010 does not work on XP

Do you see a pattern?

*snip*

I'll have to correct you on that line. VS2010 does run on WinXP because that's what I'm using here.

Btw, VS team have to drop support for older systems. Supporting 3 old(WinXP + Vista + Win7) + 2 new (Win8 + next version of Windows) would have made their support matrix too complex. It's wise to reduce it by dropping systems that no longer in mainstream support.

Btw, lots of hardware vendors have stopped to provide WinXP drivers. Companies will have to move on... WinXP is not like Win9X which you could more or less make it work with only generic drivers.

Let's be realistic here:

1. Microsoft's decision is understandable.
2. Microsoft (probably) has no evil motives.
3. XP is still in use, not just in niche markets and probably will be for the forseeable future.
4. A fair share of developers have therefore interest in XP compatibility
5. There are workarounds to the problem

18 hours ago, evildictaitor wrote

Office 2010 does not work on XP.

wrong. (unless you are talking about the obscure XP x64 edition)

IE8, never mind IE9 and IE10 does not work on XP.

wrong.  IE8 has always worked on XP.  Maybe you're thinking of IE9.

Visual Studio 2010 does not work on XP

wrong.

1 day ago, cheong wrote

@deiruch: Most companies upgrade system with hardware. With OEM suppliers banned from providing new OEM WinXP systems, the market share is expect to shrink within 3-5 years. (I heard many companies bought downgradable models on the last wave, so make it this long)

Btw, lots of hardware vendors have stopped to provide WinXP drivers. Companies will have to move on... WinXP is not like Win9X which you could more or less make it work with only generic drivers.

OEM buys make no difference. If the company has a volume license, they can continue putting XP on new machines as long as drivers exist for the hardware. With companies moving towards VMs and thin clients, it makes it even easier to stay on XP.

As much as I wish my company would move off of XP, there is no good business case for it. We'd need to test our huge catalog of internal software, purchase upgrades for another piece of software we use (and spend time and money to test it against government regs), replace older PCs with hardware that can't handle Win7 (some of our PCs are 15+ years-old), and put a massive training effort into educating our 1500+ users to use the new OS (they are not tech-savvy). It would mean at least a solid year of effort and hundreds of thousands of dollars.

And evild, you were off by a version for your non-XP software. IE8, VS2010, and Office2010 all run fine on XP SP3. The just released Microsoft Flight runs on XP SP3.

19 minutes ago, spivonious wrote

And evild, you were off by a version for your non-XP software. IE8, VS2010, and Office2010 all run fine on XP SP3.

Appears so. My bad.

VS2008 - November 2007. Drops support for Windows 98 (mainstream support January 2004, extended support July 2006). Windows 98 market share when VS2008 was released: 1.0%.

VS2010 - April 2010. Drops support for Windows 2000 (mainstream support June 2005, extended support July 2010). Windows 2000 market share when VS2010 was released: 0.5%.

VS11 - Beta February 2012, RTM 2012. Attempts to drop support for Windows XP (mainstream support April 2009, extended support April 2014). Windows XP market share when VS11 Beta was released: 30.0%. Probabilistic calculation says it'll be 24% by the end of 2012.

This clearly shows that for the first time Microsoft is trying to drop Visual Studio support for an OS that still has extended support (let's ignore Windows 2000, the gap was only a few months).

NOTE: These market shares are given if linux, mac and mobile platforms are also considered. When considering Windows machines only, Windows XP had a market share of 36% in February 2012, by the end of 2012 it'll be 29%.

http://blogs.msdn.com/b/vcblog/archive/2012/04/18/10295093.aspx

?

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!

Sounds like VS2011 will have XP support after all

In other words, in that way you lose all functionality granted by new libraries/runtimes that come with VS11. VS11 itself and native binaries generated by VS11 still won't run on WinXP. Why not just continue using your old VS2010 or earlier?

What we are complaining about is being able to compile C++11 (<thread> and others, ranged based for loop, etc.) code to into binaries that run on XP SP3 and above. While you can use the VC10 compiler from VC11, this does NOT allow you to use the new C++11 features (which the whole point of VC11 for many of us).

In other words, multi-targeting is useless for what we want.

10 hours ago, cheong wrote

Why not just continue using your old VS2010 or earlier?

Visual Studio is more than just a compiler. You might want the IDE, Intellisense and so on of VS2011, but if you care more about XP than about speed, new language features and security then perhaps you'll want the VS2010 toolchain at the backend of it.

9 hours ago, Jaukku wrote

@evildictaitor: You clearly do not understand the issue at hand. Please try not to post about things you have no idea about.

Back at 'cha.

What we are complaining about is being able to compile C++11 (<thread> and others, ranged based for loop, etc.) code to into binaries that run on XP SP3 and above.

Yeah. You can't do that - and that's the fault of your customers. They want XP. Give your customers what they want. And that's a program written in C++ < 11 using a toolchain < VS2011.

That's the reality, I think.

20 hours ago, cheong wrote

@evildictaitor:We may want the IDE, but we're not going to be able to justify the cost to upper level with just a better IDE, but without significant difference to the apperance/performance of the application we write. People who buy their own tools like me is the minority, most people just be able to use whatever programming tools provided by the company.

That's the reality, I think.

If the new VS2011 IDE improves the productivity of your staff, that's still a valid reason to upgrade - regardless of new UI/perf in the compiled application. If you have 100 staff and they all become 20% more efficient, you're working as hard as if you had 120 staff - and that 20% spare time that just opened up will make more of a difference to the look and features of your product than any amount of fancy new perf or UI that comes out of the compiler.

Just for instance, intellisense and the static analysis (warnings) in VS2011 use the VS2011 toolchain not the VS2010 toolchain, and hence even if you're compiling in VS2011 with the VS2010 toolchain there's still added benefit.

Whether that's worth the price of the upgrade is not my call - that's up to whoever pays the bills in your company and how more (or less) effective VS2011 would actually make your team.

But trying to quantify the improvement usually is wrong too. A productive team is used to current tools, so additional tools - except a long wanted one - will add little to productivity. A poor performing team won't get much improvement too becasue their problem is on another level that's not something development tool can improve. So the estimation have high chance to not look impressive enough to justify the cost, or just plain wrong.

So the XP support is really a issue for developer needing a new tool, especially since most developer is still using WinXP as development OS in companies, the cost of moving to VS11 will be "the cost of using VS11 + the cost of migrating to Vista+ systems" in their eyes. Whoever want to push buying this would certainly need impressive report to let the upper levels approve the budget.

11 minutes ago, cheong wrote

@evildictaitor:You can't prove something will improve productivity to the point that justify the additional cost. You can say that there's feature here and there that will improve the productivity, but try present that to upper management and see if they can understand!

I do it all the time. Upper management always wants you to be more productive for low cost. What they don't want is spending money for stuff developers don't want, or spending lots of money on stuff you don't need. If you say to the CEO of your company "This tool will allow us to make your products faster, safer and ready-for-market sooner" then he'll get out his check book.

But trying to quantify the improvement usually is wrong too. A productive team is used to current tools, so additional tools - except a long wanted one - will add little to productivity. A poor performing team won't get much improvement too becasue their problem is on another level that's not something development tool can improve. So the estimation have high chance to not look impressive enough to justify the cost, or just plain wrong.

If that were true, why did you ever leave Visual Studio 2003? And what possible scenario could there be where your CEO would ever allow you to buy VS2011, XP-support or not?

So the XP support is really a issue for developer needing a new tool, especially since most developer is still using WinXP as development OS in companies, the cost of moving to VS11 will be "the cost of using VS11 + the cost of migrating to Vista+ systems" in their eyes. Whoever want to push buying this would certainly need impressive report to let the upper levels approve the budget.

Your CEO doesn't care about XP or Vista or anything. she/he cares about profit margins. If 90% of your customers are using XP, you're probably not going to be able to upgrade to VS2011, but if 5% of them are, and your team will be 10% more effective with VS2011 than without, then the CEO will happily ditch those customers in order to reap the 5% marginal improvement.

1 hour ago, evildictaitor wrote

*If that were true, why did you ever leave Visual Studio 2003? And what possible scenario could there be where your CEO would ever allow you to buy VS2011, XP-support or not?

No. I quit using VS2003 since I change company. The company I worked still using VS2003 at the time. They have components that use .NET v1.1 runtime and the boss don't want to pay for the upgrade because there's no visible benefit, and .NET v4.0 which allow things be run side-by-side aren't invented yet.

EDIT: Btw, that company is a Microsoft Certified Partner which have MSDN subscription. Cost of buying VS2005 was non-existant, only the inerta of old codebase and various components.

The next company is outsourcing company that must use whatever the customers provide, be it VS2005, Java Eclipse, Foxpro or just VB coding interface of Access VBA. The programming languages and tools just varies each project.

The next company uses Java and just migrated to .NET last year, so decision for VS IDE is irrelevent.

My current company also use VS2010 from the beginning, so the decision is irrelevent too.

Your CEO doesn't care about XP or Vista or anything. she/he cares about profit margins. If 90% of your customers are using XP, you're probably not going to be able to upgrade to VS2011, but if 5% of them are, and your team will be 10% more effective with VS2011 than without, then the CEO will happily ditch those customers in order to reap the 5% marginal improvement.

Err.. first, let me correct you that the new VS is VS11, not VS2011. It's just VS2010 is also the 10th version of VS so it's shortened to VS10. (VS2008 is 9.0, VS2005 is 8.0, VS.NET 2003 is 7.1, VS.NET 2002 is 7.0, VS6 is the one with VB98... ) If anything, please name it VS2012.

Back to the topic... Except the increase in margin is generally not be seen in a short time. Remember what I said? Most users (including me) using VS2010 is still running it in WinXP. And there'll be lots of work to do for upgrading developer's machines to (Win7 I suppose). The environment needs to be set up to make sure old tools doesn't break in the new machine. There's expected dayloss to the upgrade time (okay, I'll stop here... just everything you need to do for upgrading development machine)

It's just reasonable to say that the greatest pushback is from the OS, no matter customer side or developer side. So no... having support for IDE and the runtime for longlife OS like WinXP stopped in the same version of VS doesn't sound too wise. I'd say Microsoft should drop IDE support for WinXP in VS2010, then upgrade to this version would have faced less resistance. (Just like what you said, a new IDE with productivity feature that could be available in no time - just install the new IDE and use it)

1 day ago, evildictaitor wrote

*snip*

If the new VS2011 IDE improves the productivity of your staff, that's still a valid reason to upgrade - regardless of new UI/perf in the compiled application. If you have 100 staff and they all become 20% more efficient, you're working as hard as if you had 120 staff - and that 20% spare time that just opened up will make more of a difference to the look and features of your product than any amount of fancy new perf or UI that comes out of the compiler.

Just for instance, intellisense and the static analysis (warnings) in VS2011 use the VS2011 toolchain not the VS2010 toolchain, and hence even if you're compiling in VS2011 with the VS2010 toolchain there's still added benefit.

Whether that's worth the price of the upgrade is not my call - that's up to whoever pays the bills in your company and how more (or less) effective VS2011 would actually make your team.

Now, this is what I would call grasping at straws.

You are right, whether improvements to the IDE are reason enough to upgrade to a new version of Visual Studio is not your call. Let me tell you, I have *never* seen any C++ team to upgrade on that merit alone. Never. The compiler and the tooling were *always* what the upgrades were all about.

Now, this is a big world, so I am sure you will find some developers who wouldn't care much about the compiler and would upgrade just for the IDE. But you'd be hard-pressed to show if this type of behavior is at all typical. We are not exactly newbies here. We do C++ for a living, did it for umpteen years. The compiler and the tooling always go first. End of story.

2 days ago, evildictaitor wrote

What we are complaining about is being able to compile C++11 (<thread> and others, ranged based for loop, etc.) code to into binaries that run on XP SP3 and above.

---

Yeah. You can't do that - and that's the fault of your customers. They want XP. Give your customers what they want. And that's a program written in C++ < 11 using a toolchain < VS2011.

This is simply bizarre.

We say that a lot of our customers, as well as a lot of users in general, worldwide, are still on XP. We ask Microsoft to please reconsider their decision to drop support for XP. We say that without such support we won't be able to use VC11, which would be a shame.

Your reaction is: we have bad customers. What? Really??

3 hours ago, PFYB wrote

*snip*

Now, this is what I would call grasping at straws.

You are right, whether improvements to the IDE are reason enough to upgrade to a new version of Visual Studio is not your call. Let me tell you, I have *never* seen any C++ team to upgrade on that merit alone. Never. The compiler and the tooling were *always* what the upgrades were all about.

Now, this is a big world, so I am sure you will find some developers who wouldn't care much about the compiler and would upgrade just for the IDE. But you'd be hard-pressed to show if this type of behavior is at all typical. We are not exactly newbies here. We do C++ for a living, did it for umpteen years. The compiler and the tooling always go first. End of story.

That might be true for you, but it's certainly not what I've seen in the several companies I've worked at.

Developers where I've worked have cared more about intellisense working and being able to use new tools like WPF and static analysis tools to any 5% improvement from new and clever optimisations in the toolchain.

I've even worked at a company where they used VS just as an IDE, and toolchained to GCC because they were compiling for Linux, but wanted intellisense. So I'm not going to buy your "We only want a command prompt, the IDE adds nothing" argument.

2 hours ago, evildictaitor wrote

Anyway, this thread is getting old and boring. The long and short answer is that VS11 doesn't ship with XP as a backend, but that you can toolchain it with VS2010.

Microsoft has officially replied that they will take a look.

http://blogs.msdn.com/b/vcblog/archive/2012/04/18/10295093.aspx#10296691

quote from Steve Teixeira: "The ball is now in our court, and we will follow up on this issue in the coming weeks to talk about our plan for Dev11 RTM."

11 hours ago, evildictaitor wrote

I've even worked at a company where they used VS just as an IDE, and toolchained to GCC because they were compiling for Linux, but wanted intellisense. So I'm not going to buy your "We only want a command prompt, the IDE adds nothing" argument.

I bet the VS team is thrilled about this arrangement. Perhaps they can do away with the compiler and become just an IDE, since there are so many people who'd buy VS just as an IDE. /sarcasm

The IDE does add value, of course. But don't overestimate the value of "one more" IDE, which is what VS11 is. There are plenty of good IDEs, including previous versions of VS, which people can use already. It *is* all about the compiler.

11 hours ago, PFYB wrote

The IDE does add value, of course. But don't overestimate the value of "one more" IDE, which is what VS11 is. There are plenty of good IDEs, including previous versions of VS, which people can use already. It *is* all about the compiler.

I write a lot of code in C++, and to be honest, having worked with a completely broken intellisense in 2005, I can confidently say that intellisense (read: the IDE) has made more of an impact to my productivity than any optimisations passes or language features introduced since then.

44 minutes ago, evildictaitor wrote

I can confidently say that intellisense (read: the IDE) has made more of an impact to my productivity than any optimisations passes or language features introduced since then.

So?

Like I said, don't overestimate the value of "one more" IDE, which is what VS11 is. There are plenty of good IDEs, including previous versions of VS, which people can use already. These IDEs have Intellisense.

Meh.

20 minutes ago, PFYB wrote

*snip*

So?

Like I said, don't overestimate the value of "one more" IDE, which is what VS11 is. There are plenty of good IDEs, including previous versions of VS, which people can use already. These IDEs have Intellisense.

Meh.

There are plenty of great compilers and toolchains out there too. If you don't like the Visual Studio IDE and you don't like the Visual Studio toolchain (because it won't compile for XP), why are you bothering to use Visual Studio?

you're alone in all this

Clearly not, since Microsoft employs a lot of C++ developers, none of whom are upset by dropping XP support.

38 minutes ago, MrChris wrote

IntelliSense if of course very good, but if you can't do without it you're not a good programmer.

I didn't say "I can't work without it", I said "it makes me more productive".

Anyway, I'm bored of this thread. I was just trying to give you a viewpoint you hadn't thought of. So, whatever, I don't care anymore.

/me out.

11 hours ago, evildictaitor wrote

There are plenty of great compilers and toolchains out there too. If you don't like the Visual Studio IDE and you don't like the Visual Studio toolchain (because it won't compile for XP), why are you bothering to use Visual Studio?

Nice.

So, we are saying "Microsoft, we'd like to use your compiler, but we can't afford losing support for XP, here's why, please reconsider that decision of yours", and you are saying "go away and use a different compiler". Classy.

Sorry for being blunt, but perhaps it is indeed best if you don't post any more of this nonsense you so gloriously call "a viewpoint" here.