Debunking Microsoft

When Microsoft Corp. promoted its support of Kerberos authentication in Windows 2000 as evidence of its new commitment to open standards and interoperability, only a few Microsoft stockholders and someone named Arnold from Truckee, Calif., fell for it. The rest of us yawned when the news broke that the company had added proprietary extensions that would lock customers into an all-Windows environment if they wanted to exploit all of the features of Active Directory. .

So far, the strategy has flopped, but only because customers are deploying Active Directory at about the same rate as Zero Administration Windows and the NetPC. (Remember those?)If you consider this to be Microsoft-bashing, you're right, at a superficial level, but you're missing the point. I would gladly bash IBM, but IBM lost its control over the market when it underestimated the future of the PC. That's what this is all about: control. Microsoft, like the IBM of old, is more interested in controlling your buying decisions than it is in serving your needs.

Hence the problem with the amorphous blob that is Microsoft .Net. The company is doing everything it can to sell .Net as an open infrastructure, but it's all about control.

For example, Microsoft wants you to believe that its commitment to XML means that you'll be able to share .Net-based information across dissimilar platforms. Hogwash. All XML amounts to is a standard way of pointing to things. XML doesn't have anything to say about whether the things it points to also conform to standards.

A perfectly standard XML file can say, "This thing is a title, this other thing is a menu, and this last thing is an ActiveX component." If your platform doesn't support ActiveX components, that's too bad. Since it's a foregone conclusion that Microsoft will be littering its XML with pointers to Win32-based components, the best that can be said about its adoption of XML is that it will make it easier for browsers and applications on non-Windows platforms to understand which parts of the document it must ignore.

If Microsoft was genuinely interested in XML as a means to greater interoperability, it would guarantee that its Office applications and .Net development tools would produce XML files that never point to Win32-specific components. Instead, whenever XML files point to active content, such as an executable component, that executable content should be platform-neutral. And we all know what that means, folks: Java, the environment Microsoft is dropping from future versions of Windows.

In place of Java, Microsoft is offering C#, which doesn't produce platform-neutral components. Quite the contrary: C# is designed to produce applications that keep everyone on Windows.

Microsoft is dodging this issue by trumpeting the fact that it has submitted the C# language specification to the ECMA standards organization (www.ecma.ch). This is a public relations attempt to make Java look proprietary and C# open.

The problem is that it doesn't matter how open the C# language itself may be. C# applications will rely on Microsoft's Common Language Interface for .Net in order to run.

The Common Language Interface has merit, but it's important to understand that it isn't the equivalent of a Java virtual machine (JVM). The point of a JVM is to let you run Java applications on any platform. The goal of the Common Language Interface is to let you use programming languages other than C# to write .Net applications. It does nothing to enable you to run applications on an operating system other than Windows.

Worse, the common language interface is tied directly to Microsoft-provided services like HailStorm and Passport. Even with XML, not only is .Net contrived to lock e-commerce providers and customers into running only Microsoft software, but it's also specifically designed to produce software that uses the Passport authentication service, the Microsoft-controlled tollbooth for e-commerce transactions on the information superhighway.

If this isn't enough to raise concerns about using .Net, next week, we'll look at the network security implications.

Join the newsletter!

Error: Please check your email address.

More about ECMAIBM AustraliaMicrosoft

Show Comments