Coffeehouse Thread

66 posts

Conversation Locked

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

Why is XP Support for .NET 4.5 not happening?

Back to Forum: Coffeehouse
  • User profile image
    Vaccano

    Before I dig into this question, I get that XP is over 10 years old.  And that Microsoft wants users to upgrade.

    But here are some other facts:

    • Windows XP is the most used operating system on the planet! It has 44% of the market share.  This means a high percentage of users are still using it, so developers have to support it.
    • Windows XP is still on (extended) support until April 2014.
    • .NET 4.5 is an In-Place Upgrade.  That means that once you install it, you are no longer able to see issues that will happen on a .net 4.0 machine.  (Because those dlls are gone.)

    Some people argue that it has Visual Studio 2012 has "support" for XP with the "Targeting" feature.  But this feature has so many flaws it is stunning. 

    Basically, when you "Target" .net 4.0 your compiler will tell you if you have used a .net 4.5 feature.   That is it!  Nothing else.

    But once you start running, all your runtime stuff is really using .net 4.5 (even if you are targeting .net 4.0). 

    An example of how this is bad can be found in the bugs fixed in .net 4.5.  If you are developing "Targeting" .net 4.0 and your code relies on a bug that is fixed in .net 4.5, you will not know that your code is broken (for 4.0) until you run it on a separate machine that ONLY has .net 4.0 installed.

    "Fine!" you say.  I will Remote Debug on a Windows XP machine.  But that is also not supported.

    This means that testing for .net 4.0 compatibility cannot happen at Debug time.  It must be later down the chain.  And the further down the chain it goes the more those bugs cost to fix.

    The best part about all this craziness is that it based on .net 4.5.  So those who think, "I will just install Visual Studio 2012 to use for my new apps and use Visual Studio 2010 for my old apps" are wrong.  And probably will not know it until they see bugs on production Windows XP machines that they cannot reproduce on their .net 4.5 developer machine.


    Anyway, this post is a bit of a rant.  But it is just driving me nuts that Microsoft is not supporting the most used Operating system on the planet.  They should wait until usage dies down (like they did with Windows 2000.  It was at 8% when they dropped it from .net 3.0.)

  • User profile image
    devSpeed

    Microsoft dropped support for XP in SQL Server 2012. Internet Explorer 9 doesn't run on XP. Even Adobe has dropped XP support in LightRoom 4. I think the list goes on and on but it shouldn't come as a huge suprise that a framework that ships in a OS in 2012 would work in an os that shipped in 2001.

  • User profile image
    ZippyV

    Which bugs in .net 4 bother you and what makes you think they will only be solved in .net 4.5? If you find a bug in .net 4 file a support incident.

  • User profile image
    felix9

    I think for most apps the chance of hitted by a BUG in 4.0/4.0.3 but fixed with 4.5 is quite low, very low I guess. on the other hand, 4.5 has few important new features so you wont miss it much, this is different than VC++ because C++11 is huge.

    But if .NET developers had complained about this like VC++ users did, MAYBE ms could change this.

  • User profile image
    cbae

    Not everybody is going to install .NET 4.5 on Vista/Windows 7 or Windows Server 2008/2008 R2, so they'll need to continue issuing security fixes for .NET 4.0 at the very least.

  • User profile image
    Vaccano

    @devSpeed - Server apps (SQL Server) and individual apps (LightRoom, IE 9) are not on the same scale as a all of .net.  A framework that supports thousands of apps. 

    • Server apps because upgrading a single server is a far less difficult prospect that upgrading thousands of client machines.  And the server is frequently under the control of the party that needs the upgrade.  Client apps are frequently controlled by a third party and forcing an OS upgrade is far more difficult.
    • Individual apps are also different because there scope is smaller.  Even IE that has a huge install base, does not have the wide reaching scope of that the .net framework has.

    @ZippyV - It is the bugs I don't know about that bother me.  Microsoft will not release a list of all the fixed bugs.  So I have no idea what to look out for until it has bit me.

    @felix9 - I have no idea what the chance of hitting one of these bugs is, because no one (unless you are a Microsoft insider) knows what the bugs are.  But a good example is this one: If you have a collection that is grouped and sorted, then adding the first item can crash your app.  Because I know about that one, it will not mess me up.  But I have no idea how many more like that there are.  And if I cannot see them while I am debugging then that adds $$$ to my development and/or introduces bugs to production.

    @cbae -  Security fixes are not what concern me here (though those are very important until April 2014).  I am talking about .net framework bug fixes.

  • User profile image
    cheong

    "Fine!" you say.  I will Remote Debug on a Windows XP machine.  But that is also not supported.

    This means that testing for .net 4.0 compatibility cannot happen at Debug time.  It must be later down the chain.  And the further down the chain it goes the more those bugs cost to fix.

    To be fair, even in the time of MFC, bugs show up in Win98 don't necessarily show up in Win2k. If you really concern about the impact of difference in platform / runtime that much, nothing stops you to run a WinXP VM (or physical machine) with all the development tools loaded for testing.

    Remember, all development tools on MSDN are licensed on per-user basis. So as long as all users touching that test VM are licensed user, there will be no licensing issue.

    Just install VS2012 with .NET v4.5 on your development machine for the enhanced IDE features, and install VS2010 on that testing machine for debug purpose.

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

    Just install VS2012 with .NET v4.5 on your development machine for the enhanced IDE features, and install VS2010 on that testing machine for debug purpose.

    But doing that causes me to have to debug twice.  Once for .net 4.5 and again for .net 4.0.  All for a .net 4.0 application.

    To be fair, even in the time of MFC, bugs show up in Win98 don't necessarily show up in Win2k. If you really concern about the impact of difference in platform / runtime that much, nothing stops you to run a WinXP VM (or physical machine) with all the development tools loaded for testing.

    .NET is billed as a "code once run on all platforms" framework.  Part of the reason I use it is so I don't have the same problems native developers have between operating systems.

    Having several machines is a workaround.  Something I would (and could) do if I were developing for an operating system that is seeing 5% - 9% market share.

    But Windows XP has the most market share out there!  (A whopping 44%)  Of all operating systems on the planet, it has the most.  Workarounds for dropped operating systems should not have to be applied to an operating system that 44% of my and your customers are using. 

    I look at the numbers and I am confused as to what Microsoft is thinking.

  • User profile image
    elmer

    "But Windows XP has the most market share out there!  (A whopping 44%)  Of all operating systems on the planet, it has the most"

    I think that's only true if you include Asia, where there is massive use of pirated XP.

    According to NetMarketshare.com
    -----------------------------------------------------
    Nth. America:  XP: 26%  Win7: 48%
    Sth. America:  XP: 34%  Win7: 54%
    Europe:           XP: 32%  Win7: 46%
    Australia:        XP: 23%   Win7: 47%
    Africa:            XP: 39%   Win7: 51%
    Asia:              XP: 57%   Win7: 34%

    In all regions other than Asia, use of XP is falling steadily and Win7 rising at the inverse rate.

  • User profile image
    cheong

    @Vaccano:

    , Vaccano wrote

    But doing that causes me to have to debug twice.  Once for .net 4.5 and again for .net 4.0.  All for a .net 4.0 application.

    You code in .NET v4.5 and test on .NET v4.0. Or you can just use VS2010 and "code and test" all in .NET v4.0. It's a matter of choice.

    IMO, you should always debug on the major platform you're going to support. That means if your company decide to major support WinXP, you should debug in there anyway, even if .NET v4.5 somehow backported to support WinXP.

    @Vaccano:

    .NET is billed as a "code once run on all platforms" framework.  Part of the reason I use it is so I don't have the same problems native developers have between operating systems.

    Having several machines is a workaround.  Something I would (and could) do if I were developing for an operating system that is seeing 5% - 9% market share.

    But Windows XP has the most market share out there!  (A whopping 44%)  Of all operating systems on the planet, it has the most.  Workarounds for dropped operating systems should not have to be applied to an operating system that 44% of my and your customers are using. 

    I look at the numbers and I am confused as to what Microsoft is thinking.

    Not exactly.

    If your application will do "Administrators" tasks, you should expect UAC on Vista+.

    If your application store setting on you application folder but you don't need it to "Run as Administrator", you should expect the setting files could be virtualized on Vista+.

    If your application need listen to the network, you need to cater with firewall on WinXP SP2+, and there are different interface to set firewall rule on WinXP/2003 or Vista/Win2008+. And depending on the type of machine you're going to support, you probably need to care about sleep/resume too.

    If your application need to support CJK character, because of difference in codepage version being supported (this matters more for we Hong Kong people, because both the change from Unicode 5 to 6 and include of Big5-HKSCS matters to lots of us) Characters legel to be displayed in Vista doesn't mean it can be displayed in WinXP (without government issued patch, which known to have problem to be installed on Win2003 SP2).

    So no, if your application will have to expect difference on OS level even if the .NET runtime version is the same.

    For argument regarding "Windows XP has the most market share out there!". It's probably still true depending on area you're in. But bear in mind it's market share is diminishing because Microsoft has already cut the retail licensing. And because lots of companies have audit rule that disallow software which no longer have security related updates, lots lots of the companies have started planning to migrate to Win7. It's up to your company to decide when to cut WinXP support. (Remember, for each OS your application decide to support, there's a support cost added on the bill.)

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

    Since you can't run VS2012 on XP, you'd have to test on a seperate machine for XP compatibility anway - even if there was .NET4..5 on XP, the bugs you encounter might be *in* XP itself.

  • User profile image
    ZippyV

    @Vaccano: What kind of applications do you sell and who is your target market?

  • User profile image
    Vaccano

    @elmer

    Nth. America:  XP: 26%  Win7: 48%
    OK, I can agree with that.  But still a full quarter of all computers no longer able to use the current .net framework?  And in fact anti-supported? 

    It seems crazy that Microsoft would cause all these difficuties for 1/4 of all their users.  Though really, they are just causing them for me.  Because I can't say to 1/4 of my user base, too bad, you have to upgrade (not if I want to stay gainfully employed that is).

    @cheong

    You code in .NET v4.5 and test on .NET v4.0. Or you can just use VS2010 and "code and test" all in .NET v4.0. It's a matter of choice.
    Yes I could, and will be, staying on Visual Studio 2010 and .Net 4.0.  But why do I have to be left behind?  Why is microsoft ignoring such a large part of the user (and thus developer) base?
    If your application will do "Administrators" tasks, you should expect UAC on Vista+.
    You are correct, there are differences between the versions, but these are not subtle hidden issues/bugs.  They are well documented changes/differences.  There is a huge difference between the two.

    @AndyC
    We do test on XP machines.  But that is not the point.  Testing for bugs that would normally be found at Debug time extends the testing process.  And increases the likelyhood of bugs getting to production.

    @ZippyV
    I work in the Medical Industry creating applications for data entry.  (That is why this issue frustrates me so.  If these hidden bugs get to our production version then it can impact a patient's care (very bad day for everyone).)

  • User profile image
    cheong

    , Vaccano wrote

    @cheong

    You are correct, there are differences between the versions, but these are not subtle hidden issues/bugs.  They are well documented changes/differences.  There is a huge difference between the two.

    Not everything is that obvious. The inability to install government made patch for HKSCS in Win2003 Server is not known to us until we try to install that and the server won't boot even to safe mode afterwards. We do it again on clean installation and fail again to confirm this. And you'd think since WinXP and Win2003 use the same kernel, software that can run on WinXP could be pretty sure be able to run on Win2003?

    Because the HKSCS character "邨" (which means "estate") appear in 20-30% of Hong Kong addresses, inability to handle this on the server is a very significant bug to us. Actually we even created a test case specifically testing for this - just that the tests are only run on WinXP and never on the server before UAT.

    After this incident, it's very clear to me that if you're going to support a platform, you have to debug the program on the platform the software is going to run on.

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

    , Vaccano wrote

    It seems crazy that Microsoft would cause all these difficuties for 1/4 of all their users.  Though really, they are just causing them for me.  Because I can't say to 1/4 of my user base, too bad, you have to upgrade (not if I want to stay gainfully employed that is).

    Unfortunately, it's not as simple as that.

    If you look at the stats, the XP base has been falling at a steady rate of about 2% per month, so your XP base will continue to decline quickly if it's in line with the general demographics.

    Furthermore, o/s version and the age of the hardware it's running on, tend to be closely linked, as most people (and businesses) don't perform major version upgrades on hardware, they replace hardware with new versions loaded. XP's age tends to suggest that the hardware is well due for replacement in a large proportion of cases (even if they were downgraded from Vista) and MS are about to release a shiny new version with interesting new hardware options supporting it... expect the XP base to take a further big hit as a result.

  • User profile image
    davewill

    , devSpeed wrote

    Microsoft dropped support for XP in SQL Server with 2008 R2 SP1. *snip*

    Where is the support policy defined for SQL Server that states that?

    The documentation lists Windows XP for several flavors of R2.  Subsequent service packs wouldn't remove that ... surely?

    http://msdn.microsoft.com/en-us/library/ms143506(v=sql.105).aspx">http://msdn.microsoft.com/en-us/library/ms143506(v=sql.105).aspx

     

  • User profile image
    ZippyV

    , Vaccano wrote

    @ZippyV
    I work in the Medical Industry creating applications for data entry.  (That is why this issue frustrates me so.  If these hidden bugs get to our production version then it can impact a patient's care (very bad day for everyone).)

    You are looking at the situation in the wrong way.

    • Your target market doesn't even come close to what Hitslink displays. They are 2 different environments. The marketshare of Window XP might be a lot higher or lower with your customers.
    • If there are bugs affecting your applications then you didn't test enough or the bugs don't affect your software.
    • You seem to forget that a new version can introduce new bugs.

     

  • User profile image
    spivonious

    , elmer wrote

    *snip*

    Unfortunately, it's not as simple as that.

    If you look at the stats, the XP base has been falling at a steady rate of about 2% per month, so your XP base will continue to decline quickly if it's in line with the general demographics.

    Furthermore, o/s version and the age of the hardware it's running on, tend to be closely linked, as most people (and businesses) don't perform major version upgrades on hardware, they replace hardware with new versions loaded. XP's age tends to suggest that the hardware is well due for replacement in a large proportion of cases (even if they were downgraded from Vista) and MS are about to release a shiny new version with interesting new hardware options supporting it... expect the XP base to take a further big hit as a result.

    Don't underestimate IT departments. We buy new Windows 7 machines, wipe them, and put XP on with our volume license. I really hope that the pending end of security updates forces us on to Win7, but I think we'll keep using XP until hardware vendors stop making drivers for it.

Conversation locked

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