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 proponentof Microsoft technologiesin 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 startingto talk about Longhorn, and the message I am getting is that contrary toyourpolicyup totoday,it seems that there will be no backward support for most of the Longhorn technologies.I am personally interested in Avalon and itspromiseto bridge the gap between UI designers and software developers.In Avalon,the developer canalwaysimplement any GUI designed by the graphic designer.TodayI always getGUI that is easy to implement…

However,anybody writing "out of the box" software, that needs to be installableat 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 runson any supported Microsoft platform.There is no way we will be able to split our implementation into abranch using Longhorn, and abranchusing "legacy ..NET"– tooexpensive.

Thus, as things stand now, I face the prospect of not being able to use any new clienttechnologyafter .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-productI"make sure"they are not portable to competing platforms.You inreturn make sure I canuse the most current technologies available, as soon as they are released.Now I am afraidtheJava 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 decisionnotto support legacy platforms is not an item for a feature review
within the Longhorn team.It is a strategic decisionthataffects the ability of allIndependentSoftware Vendorstoadopt Longhorn technologies, the next majortechnologybreakthrough.I would much preferto get a Longhorn with less features, but one I can use, than having a very advancedLonghorn that I willhave to wait manyyearsto use.

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?

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.

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 Although if anyone here had a different experience with this stuff, I'd be interested to hear about it.

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.)

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.

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.

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).

Thread Closed

This thread is kinda stale and has been closed but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.