by Michael S. Kaplan, published on 2010/12/06 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/12/06/10100616.aspx
Okay, this is unlikely to be a series, so pretend the title doesn't have a #3 in it.
The inmates are still running the Unicode List asylum, so the situation is normal....
A recent thread entitled Samogitian E with dot above and macron proved the point once again....
After some of the typical bitter diatribes about evil Microsoft which I'll skip since you can just go to alt.i.hate.microsoft to see that kind of thing and don't need it here, the tail end of the thread (as of last night) was in this message:
Peter Constable wrote:
> Updates to any Windows component in a given version of Windows will
> rarely add new functionality. This is the case for reasons of
> compatibility and stability: for too many users, any change in
> functionality entails unwanted costs either in the form of re-training
> or in the form of incompatibility risks.
I know this has been said before, but: I do wonder how many users depend
on new, incremental functionality *not* being available, as a matter of
stability or backward compatibility.
"Dang it! Microsoft added support for Bamum and Brahmi and Mandaic to
my XP system! Everything is broken now!"
(Yes, I know there are a few people who would say just that.)
If the goal is to get people to update to 7, it might be better PR to be
honest and just say so.
--
Doug Ewell
To be honest (which I bring up since Doug did, and not to contradict Peter!), the biggest factor involved with even the potential backport is the huge test matrix one would have to plan out, which is only partially an AppComapt issue.
This test matrix is complete with:
If you are a tester you might already be thinking about what that breakout might look like.
Oh yeah, you also may have to have someone test Office (which builds on Uniscribe and often has trouble with tweaks between versions, which is why some parts of use their own), and SQL Server (whose Reporting Services also make use of Uniscribe, or in earlier verions GDI+).
If you don't also update fonts (to try to reduce the test matrix), then support can also not be there and font fallback schemes might fail.
Wait, many new characters aren;'t in the sorting tables.How the hell can we say we support something if it compares equal to "" (an empty string)? Crap, we'll have to test that too, if we add the support.
Or in the keyboards. How the hell can we say we support something if it can't be typed? Ditto on the Crap, and on that testing, too.
But if you do update fonts then you also have to make sure you didn't break GDI+.
Or WPF.
Or Silverlight.
Like Windows really needs another conspiracy theory rumor about Windows/DEVDIV adversity that a Windows breaking of any of those three components would inspire, especially after the recent Silverlight ruckus that made me realize we probasbly should pay Bob Muglia and Gu more than we currenly do. And maybe some other execs a scosh less. :-)
Then add all the third parties whose support could be broken, just the same. If Microsoft keeps Office from breaking but breaks something Adobe or whoever is doing, then that would really suck. So there had better be a bunch of AppCompat testing, too.
Of course each thing that fails in all of the above will be entirely Microsoft's fault for missing, and since many of those broken didn't care about new script support, they will only want to know how the hell to uninstall.
Which is why all that testing would have to happen.
At that point, when you have made the business decision to delay future work so you can test all of the above so that an OS that shipped way back in 2001 can support scripts not even added to Unicode until 2-8 years later, someone will almost surely tap you to wake you up from the nightmare....
TRIVIA: Did you know that installing Beta XP SP2 could cause a managed application written by a customer to crash, due to the added support and fonts for Bengali and Malayalam? It's true. The bug was always in GDI+ is you had a valid Bengali or Malayalam OpenType font, which we had not as of then ever shipped. So once we wanted to ship one in Windows in a Service Pack, this non-windows component broke. If the testing had not been done and that bug shipped, who would have been blamed?
TRIVIA #2: I was kicked off one of three contracts I was doing for Microsoft (I was a vendor at the time) for my annoying and loud insistence that the GDI+ bug be fixed here. The conversations surrounding that, combined with the fact that the tester who originally found it was testing my component at the time, gave me a unique view of the anger and venom of the management aned executives in other divisions when random teams break their code and put the burden of unscheduled work put upon them!
Now I am not anti-conspiracy theory -- just wait until I write up my Ampyra pharmeceutical conspiracy theories, and you'd already probably read up on my health insurance changes conspiracy theories. And those theories will actually be hitting my bottom line a lot more directly than the "Unicode 6.0 on XP" issues are hitting armchair legalphiles on the Unicode List like Phillipe.
But with that said, I suppose, since one of the things that happens when a new version of Windows ships is pretty much all of the above testing (with every group owning some of the "test your stuff on Windows" work item), you could make the claim that "Microsoft should just be honest" and say that the restriction is just to get people to upgrade. In a way, since it is considered required to do that work to make the claim that new things are supported, it is technically a push to upgrade. No one agrees to do that work out of band, or randomly for random versions of components and fonts and versions.
Just like I can put BREATHER on my income tax form for my profession, since I spend my entire time at work breathing and could claim that my employer does not support me stopping such activities during business hours.
Though the actual truth is just a little more complicated....
yuhong2 on 6 Dec 2010 9:02 AM:
Anyway, this reminds me of the discussion of why true PAE support was not added to XP SP2 as an optional feature that can be manually enabled to access more than 4GB of RAM. I discussed it with Larry Osterman and Geoff Chappell, who found out that it was not only disabled, but some of the needed code was also COMPILED OUT in the XP SP2 codebase!
John Cowan on 6 Dec 2010 9:07 AM:
And that's why you eventually can't keep old systems running and end up having to scrap everything and start over. The burden gets to be too great.
Unfortunately, keeping the old systems running is Microsoft's chief cash cow at present.
Michael S. Kaplan on 6 Dec 2010 2:26 PM:
We are actually prolonging the ability to avoid doing that and avoiding the need to do that with the current scheme....
referenced by