Coffeehouse Post

Single Post Permalink

View Thread: Backward Suppor for Longhorn Technology
  • User profile image

    Hi Adam,

    First, let me say that your concern has been heard here -- the email you privately sent last week to one of the MS folks you met has already been in circulation among the evangelism team here in Redmond.

    As bitmask notes, there is always a tug of war between a desire to do innovative new work vs. support older platforms.  Windows apps don't run on DOS.  Mac OS X apps don't run on OS 9.  Without that sort of clean break, it's really hard to take revolutionary steps forward in the platform.  And what was the old joke about Java -- write once, debug anywhere?

    The good news is that we continue to support the core .NET platform (CLR and core FX classes) on a bunch of versions of Windows, as is evidenced by the upcoming Visual Studio 2005 release.

    Let me paste in part of what I wrote in response to the internal thread:

    What I think we really need to do is address this concern:

    >> There is no way I will be able to split my implementation into a branch using Longhorn, and a branch using "legacy ..NET" – too expensive.

    with an excellent set of prescriptive architectural guidance (PAGs) and tools that actually make it easy to write an app that works amazingly well on Longhorn, but downgrades reasonably when run on XP.  Nothing we can promise yet, but I think everyone recognizes the importance of this guidance.

    If you look at what we are doing in LH, it is a huge integrated package.  Avalon and WinFS are relying on changes throughout the core OS. Imagine if you hacked your way to putting the Avalon DLLs on XP (I think someone published a hack to do this in the PDC timeframe, actually), but then only 90% of the functionality worked, and 20% of what did work was buggy and strange (for example, animations and 3D models that ran smoothly on LH looked jerky or wrong on XP)  Or doing the same thing with WinFS, and finding that transactions over files and meta-data weren't behaving quite right.

    This is my understanding of what happened with Win32s, or the *W (eg: RegOpenKeyExW) unicode APIs that got back-ported from the NT codebase to win9x.  They were incomplete and just didn't quite behave the same, and as a result it was a sort of lose-lose situation.  MS spent time and resources on a project that just ended up frustrating ISVs anyhow.  This is not an equation we'd like to repeat again Wink  Although if anyone here had a different experience with this stuff, I'd be interested to hear about it.