Coffeehouse Thread

9 posts

Backward Suppor for Longhorn Technology

Back to Forum: Coffeehouse
  • adam_sg

    I have discussed the issue of support for Longhorn technologies on existing platforms with some Microsoft people I met during the Tech-Ed in Eiat a couple of weeks ago. One of them, Yosi Taguri, suggested that I post my concerns on this site, so here it is:

    As a proponent of Microsoft technologies in Tecnomatix, I was always proud to introduce to Tecnomatix new productivity enhancing technologies from Microsoft. I was also proud to be able to be an early adopter of these technologies, as all major technological breakthroughs I wanted to use were always available on all supported platforms (.NET being the latest example).

    Now, Microsoft is starting to talk about Longhorn, and the message I am getting is that contrary to your policy up to today, it seems that there will be no backward support for most of the Longhorn technologies. I am personally interested in Avalon and its promise to bridge the gap between UI designers and software developers. In Avalon, the developer can always implement any GUI designed by the graphic designer. Today I always get GUI that is easy to implement

    However, anybody writing "out of the box" software, that needs to be installable at different customers, using different Microsoft platforms, will not be able to target these new technologies. We would have to wait until Longhorn becomes a legacy platform before we could program to these new APIs, as we must make sure our software runs on any supported Microsoft platform. There is no way we will be able to split our implementation into a branch using Longhorn, and a branch using "legacy ..NET" too expensive.

    Thus, as things stand now, I face the prospect of not being able to use any new client technology after .NET 2.0, for many years. I see this as a breech of an unwritten contract I had with Microsoft. I push your technologies into my products, and as a bi-product I "make sure" they are not portable to competing platforms. You in return make sure I can use the most current technologies available, as soon as they are released. Now I am afraid the Java proponents in Tecnomatix will gain power as they claim Microsoft is not even compatible with itself, as opposed to Java that will run on any platform.

    The decision not to support legacy platforms is not an item for a feature review within the Longhorn team. It is a strategic decision that affects the ability of all Independent Software Vendors to adopt Longhorn technologies, the next major technology breakthrough. I would much prefer to get a Longhorn with less features, but one I can use, than having a very advanced Longhorn that I will have to wait many years to use.

    Thank you

    Adam Shaked Gish

    Software Architect

    MPM Applications Group

    Tecnomatix Technologies

  • UdoSchroeter

    I push your technologies into my products, and as a bi-product I "make sure" they are not portable to competing platforms. You in return make sure I can use the most current technologies available, as soon as they are released.

    Ahh, how refreshing, always working in the best interests of your customers, I see...

    Now I am afraid the Java proponents in Tecnomatix will gain power as they claim Microsoft is not even compatible with itself, as opposed to Java that will run on any platform.

    Eh, .NET executables also run on many platforms, have a look at Mono or Rotor or whatever. That's supposed to be one of the benefits of managed code, isn't it? 

    I would be greatly suprised if MS dropped support for anything major they introduced in the last years. Where did you get that from?

  • bitmask

    The problem Adam has isn't about dropping support for past technologies, it is just the word at the moment seems to be pretty clear that Avalon will be for Longhorn only. There are always these rough transition periods in the march forward (DOS vs Windows, Win16 vs Win32). Seeing as how we are still looking so far into the future it is hard to picture what the migration plan will look like.

  • jmazner

    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.

  • tinytiger

    While I'm not entirely sure of how Avalon will work, I imagine VG.NET is an excellent preview of what is to come. You can use it as a transitional technology until Avalon is complete or until Longhorn becomes mainstream.

    It's a very powerful animated vector graphics library that can be used anywhere .NET is used today and even has an IDE snapin that allows you to draw graphics that can be translated right into C# classes (and maybe also VB.NET, but I'm not sure.) 

    It also has MyXAML support.

    You can find out more about that here:
    http://www.vgdotnet.com

  • Frank Hileman

    Wow, tinytiger, thanks for the nice post! It is true: there is no need to wait for Avalon for animated vector graphics. The integrated VG.net designer does generate VB.net code in VB projects -- we just use the codedom serializer, exactly like windows forms. It is completely intuitive -- set properties, attach events, to any graphical object, using the property grid.

    On this blog you can see how to create transparent gel buttons with VG.net:
    http://weblogs.asp.net/frank_hileman

    The run-time is free, and there is a free designer version -- give it whirl.

  • eagle

    To join in on the spectacular graphics of Avalon we will all need the latest and greatest graphics cards.

     

    The GPU will be playing a much more important role in the Longhorn OS.

  • adam_sg

    Hi All

    Thank you for taking the time to respond to my email, and my appologies for not monitoring in in real time.
    I can understand the desire and need for a "clean break". Twice a month I find myself wishing I could have a clean break, and just rewrite my software instead of carrying all those legacy technologies and probems on my back. But it just doesn't work that way. I am also not sure you can compare the situation today to the move from DOS to Windows. There is much more code out there today, it is more complex, and more expensive to rewrite.
    All I am realy looking for is the ability to write great Longhorn code that runs reasonably on XP. A set of PAGs and tools might help, but what I would like to see is something in the direction of configuring the IDE to work in "Compatibility mode" preventing the developer from using features that will not work in XP. I would probably need a way to filter toolboxes and wizads that produce "Longhorn only stuff", and a compiler switch that will generate an error where the code is not XP compatible. If the guidance remains "on paper", I might personally be able to read and understand it, but I expect the avarage developer will atempt to use whatever is available to him.  
     

    VG.NET looks cool. I will look into it!

    Adam

  • sbc

    bitmask wrote:

    The problem Adam has isn't about dropping support for past technologies, it is just the word at the moment seems to be pretty clear that Avalon will be for Longhorn only. There are always these rough transition periods in the march forward (DOS vs Windows, Win16 vs Win32). Seeing as how we are still looking so far into the future it is hard to picture what the migration plan will look like.



    The difference between the transition between DOS and Windows is that they are completely different - DOS being mostly text based, and Windows being GUI based. It would also prove to be a lot more expensive as well.

    Also, there are far more Windows users than there were DOS users, and there is much less incentive to move to Longhorn - i.e. how would it benefit people who do just Word Processing and email?

    What I see in the future is Microsoft having a much smaller market share. If you want basic feature, stick with what you've got (2000/XP) or go with someone else (Sun, Novell, Redhat, IBM). However, if you want the latest (Microsoft) bells and whistles, go with Longhorn (although other OS's will still have compelling features).

    It is going to be a lot harder to sell Longhorn than it was to sell Windows 3.1/95. Also, there are people switching to Linux (which will unlikely switch back to Windows). Even moving to .NET is not always the best choice (except perhaps for ASP.NET) - if you have programs written in VB6, why rewrite them in .NET, what benefits will users of that program get? If there was a tool that could convert a VB6 project into a VB.NET project, maybe people will migrate (even then, the .NET runtime is required - VB6 runtime is a lot smaller, and is already installed on most PC's).

    Microsoft will find it hard to keep its existing customers, it will also prove near impossible to get Linux users to switch back (as they have far more options - having problems with Sun? Go with Novell/Redhat/IBM).

    Do not underestimate the appeal of Linux - it is here to say (and Microsoft can't really embrace it, as it will require a big change in strategy).

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.