The Problem of Integration (editorial)

Warren E. Downs has written an awesome editorial on the future of openness, Microsoft's monopoly, the browser integration issue and more. the following was written by Slashdot reader Warren E. Downs

The Problem of Integration By Warren E. Downs Systems Engineer
In the last few years, and especially in the last few months, Microsoft Corporation has come under increasing fire for monopolistic practices. While people are trying to define what is or isn't a monopoly, however, many have overlooked an important underlying issue: Where should the Operating System be separated from it's applications? While there has been some debate on this issue, most of it has focused on extremes.

On the one hand, Microsoft points out the desirability of integrating new features into operating systems and the past precedent for doing so. (See Microsoft's article on integration, and this news article about their latest attempt to halt the DOJ investigation). On the other hand, the U.S. Department of Justice is working to stop the integration of Internet Explorer into Windows. The average person, looking at this situation, might concede that, yes, it is desirable to have these features integrated into the OS. Never mind all the companies put out of business by such action.

I believe both sides are overlooking something. Yes, I agree, it is nice to have disk compression, defragmentation, virus scanners, browsers, speech recognition, etc. built into the OS. What isn't so nice is that, at least in Microsoft's case, users lose the freedom to choose alternatives. Oh, you say, but people can always choose Netscape as their browser. It's not that hard to download and install.

You're right-- Netscape (or your choice of speech synthesis, disk compression, etc.) are easy enough to install, but when you do install them, you'll notice they are never as integrated as Microsoft's solution. Never quite as full featured. There's a reason for that, and it has nothing to do with the technical feasibility of integration. It's called Legal Precedent.

In the case of disk compression, remember a company called Stac Electronics? Back in the days of DOS, their product, Stacker was _the_ disk compression for DOS. There was a competing product called DoubleSpace. Then it was bought by Microsoft. Then it was integrated into DOS. (Specifically, Microsoft modified DOS so it could load DoubleSpace _before_ loading the remainder of DOS. This meant you no longer had to maintain two copies of config.sys and autoexec.bat. This is a great feature-- if only Stac Electronics could have added it to their product.

Oh, now I remember! They did! They reverse engineered the proprietary interface between DOS and DoubleSpace, and modified Stacker so it would interface with DOS in the same way that DoubleSpace did. The only problem? Microsoft sued them. And now, about the only reference you hear to Stacker, is in relation to DoubleSpace.

Now, obviously, if a company wants to make a profit selling software, it can't just let people go around reverse engineering things, can it? In the hardware arena, reverse engineering is common. Take a look at the Intel processor clones produced by AMD and Cyrix. They were able to reverse engineer the "interface" between Intel hardware and the software that runs on it. Of course, a large part of that interface was documented, otherwise software developers wouldn't be able to use it. (Of course, there's no guarantee of equal access to documentation, what with all the NDA's-- Non Disclosure Agreements-- Intel requires people to sign).

My point is, however, it is possible to make Intel-compatible processors without having to copy the circuit traces using a microscope (which would definitely be illegal under U.S. law). But the line between legal reverse engineering of software and piracy of software is much thinner. Tracing the execution of an OS with a debugger doesn't suddenly halt when you move from an application into the OS. Furthermore, how do we determine where the applications end and the OS begins? What was once an application-- DoubleSpace disk compression-- is now part of the OS.

This is an issue I feel should be further studied by knowledgeable, unbiased, computer scientists. But I do have an immediate solution. I don't think we should restricting Microsoft from including new technology into the OS-- This would be unfair to Microsoft, but far worse, would restrict other OSs from integration, if it did become law. Take a look at the speech recognition being integrated into OS/2. Unix, too, has it's share of integration taking place. For example, KDE, a Desktop Environment for X-Windows, includes an integrated browser in much the same way as Microsoft. The difference is, the interface between KDE and the OS is documented. The interface between IE and Windows is not documented.

My solution to this problem is to require Microsoft to document the interfaces between any module (read DLL or collection of DLLs) and the other modules of the OS. After all, if Microsoft can easily interchange components of it's OS, it's only fair that others be allowed to do so as well. Just think what this would do for us. As users, we would have the choice of which Memory Management module, Disk Compression module, Browser module, etc., we wish to use. We would not be forced into only once choice by Microsoft's proprietary interfaces. (This assumes someone writes alterate modules, of course, but with the interfaces documented, I predict there would be a flood of new innovation in the area of alternate modules for Windows).

For Microsoft's part, it might appear they would get the short end of the deal. But, in the long run, it would be better for Microsoft and everybody. Having open interfaces between software modules is like having unrestricted trade between nations. It opens up competition. Microsoft's modules would have to get better to compete with all the other choices of modules out there. And as long as they were better, Microsoft would still get a healthy share of the market. But innovation wouldn't be stifled, as it is presently.

If Netscape wanted to make their browser a plug-in replacement for Internet Explorer, they would have to modify it heavily to support all the interfaces that IE does-- adding COM interfaces for other programs to make use of Netscape for the Win98 help browser, for instance. But, if Netscape (or some other company) was successful in doing this, we would have alternatives to using IE-- and they might even be better.

Now a few comments from Rob...

The major issue that I see is that Microsoft currently documents much of their APIs, and will try to use that to prove that they already are doing this sort of thing. The problem is that they design the API, and control both ends of it.

For example, when OLE came about a few years back, Microsoft Compilers were the first to support them. What office application suite supported them first? Office 4 of course. Microsoft created a spec, and because of their control of the operating system, it became defacto. And because they designed the spec, they had the first products to support it. And the rest is history.

This is happening with other specs as well- DirectX and Direct3d seem like a good example. Microsoft releases the first apps that support these standards, and integrates them into the OS so everyone has it. Can any other game company do that? Of course not.

If these APIs and specs are developed by a third party, and MS was split into seperate entities that had no special access to these third parties, the future would look much brighter.

What do you guys think?