Comment Articles

Longhorn: The nuts and bolts

John Carroll ZDNet.com

Published: 04 Nov 2003 15:55 GMT

Such a move is unique in the industry. No one, including Sun Microsystems, has made Java THE API for programming a particular OS, much less declared that, going forward, all new features would be offered through Java. Microsoft's decision to do that with .Net is an important advance, as it FORCES developers to write more secure code, simply because they can't make some of the coding errors (such as buffer overruns) that form the lion's share of security flaws.

WIN32 will still exist for backwards compatibility, of course, and native access APIs will exist for those applications which need it (though I suspect that many of them will call the managed APIs through COM Interop). However, Microsoft intends to ensure that all Longhorn functionality is accessible from a 100 percent managed program.

A side benefit of the transition to .Net is that it has given Microsoft an opportunity to revisit all aspects of the Windows API. The new "refactored" Windows API is more internally consistent than WIN32, an API that still bore the legacy of design decisions 10 to 15 years out of date, and felt strongly like an API built by many different groups within Microsoft (which it was). The new, cleaner Longhorn API simplifies development considerably, and makes the platform much more approachable to new and existing Windows developers.

Returning to the point I made at the start of this section, where Longhorn leads, the rest of Microsoft's application library will follow. If the Longhorn API is .Net, then it doesn't take a rocket scientist to figure out that a sizable percentage of Microsoft's applications released in Longhorn timeframes will largely be built with .Net. That's a large amount of code transitioned to a particular managed runtime environment, and will pull even more developers down the .Net path (that is, those not already pulled by the higher rates offered to .Net programmers).

The New Graphical Interface: Avalon
I've noticed before that it is much easier to create reasonably complex user interfaces in HTML than in WIN32. For instance, it's far easier to write a "skinnable" Web site than it is to write a "skinnable" WIN32 application. Granted, you could do practically anything you wanted in WIN32, but if you wanted to escape the look and feel imposed by WIN32 controls, you had to perform a bunch of programming gymnastics.