by Michael S. Kaplan, published on 2005/12/20 19:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/12/20/506087.aspx
I do tend to go on about compatibility -- the need of software that runs to be compatible with the way it used to run is pretty important.
Of course this problem is sometimes even more complicated.
The .NET Framework was developed during an interesting oasis of time when no new locales were being added and no new sorts were being created.
It was a good time to have a framework, since you were (from a globalization standpoint) compatible with both prior versions of the .NET Framework and the OS on which you are running.
The situation is different in Vista (well, with most versions of Windows, since in every other version we did make all kinds of additions) -- we have been updating.
But now let's take the .NET Framework 2.0 (Whidbey) running on Windows Vista (Longhorn):
Now both of these groups can come up with crucial scenarios that will break their applications completely if the compatibility bar is not kept. And you would not have to work too hard to come up with scenarios that each group has a specific requirement for that conflicts with the other group.
I mean the .NET Framework is not unique in time, since it has prior versions and that behavior to contend with.
And it is not unique in space since it works with the OS on which it runs to provide services and functionality.
So it is easy to say "be compatible", but then the big question comes up -- compatible with who, exactly?
Note that this question is not yet in the "answer" stage, though I will post more when more is decided about this issue....