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

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?

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.

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

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.