But whether Judge Colleen Kollar-Kotelly will recognize this basic customer requirement in controlling Microsoft's future behavior remains to be seen.
Your local hard drive is a file system, as are the hard drives that are used by Web servers. Both file systems get accessed by users. The physical characteristics of a conduit between the CPU and the drive, whether it's a PCI bus or a network like the Internet, shouldn't matter. In accessing file systems, no matter how close or far away, a user should be fully insulated from the intricacies of that conduit by virtue of a common user interface. IE is one of just that, and the features that are built into IE are largely what make the Windows user experience what it is.
Forcing Microsoft to allow for IE's removal not only undermines that user experience, but also opens up end users who require support to a potential nightmare. If Microsoft intended IE to be an integral part of the end-user environment, removing IE makes that environment less predictable and, therefore, more difficult for Microsoft to support. To be clear, protecting Microsoft's interests shouldn't be a goal of any of these proceedings. The company is powerful enough as it is. But the company, like its competitors, clearly has a right to build a predictable and supportable environment that evolves according to the needs of its customers. Few would argue that users need a consistent interface to all file systems they need to access, regardless of where the final storage device resides, or all the protocols that may be required to complete the task (SMB, IPX, HTML HTTP, NFS, FTP, etc.). More power to any company that insulates us from the old cliché: the greatest thing about standards is that there's too many of them. This couldn't be truer when it comes to opening files.
In the bigger picture, the role of the operating system has traditionally been to provide a layer of abstraction between the user and the file system as well as other system resources (e.g., the graphics system). The full name of Window's predecessor DOS--disk operating system--seems to drive this point home.
The sheer success of Windows as a mainstream desktop operating system over available alternatives is a testimony to the fact that Microsoft may have understood a principal customer requirement that other desktop operating system vendors failed to grasp: The operating system had to evolve according to the environment in which it lived. Requiring users to be system engineers to deal with that environment is simply a bad business decision.
Dating back to DOS and beyond (CP/M, Unix, etc.), Microsoft and its operating system competitors have established a pattern of abstracting distributed file systems to end users through a consistent interface. In the days when Unix still had a fighting chance against Windows, Unix vendors did little to deal with foreign file systems. If a Unix system needed to access a non-Unix partition, the machine hosting that partition would have to adapt to Unix by first running the TCP/IP networking protocol, and then becoming a network file system (NFS) server. When a Unix computer "mounted" an NFS volume from across a network, it referred to that volume with a fairly unfriendly string of characters and slashes. But at least the interface, which could be aliased with something friendlier, was consistent.
Whereas foreign file systems had to adapt to Unix to allow Unix workstations to access them, DOS did the opposite by adapting itself to foreign file systems. Unix bigots will argue that NFS and TCP were IEEE standards that Microsoft should have conformed to in the first place. But Microsoft was hardly responsible for creating non-standard file systems that needed to be shared across a network. Novell's Netware, DEC's Pathworks, and 3Com's 3Share (one of the first network operating systems) just to name a few were all "non-standard" file systems. Of the prevailing client operating systems--DOS, Macintosh, and Unix--that would need access to all of these network filing systems, only DOS ended up fully outfitted for the task. But even that wasn't Microsoft's doing.Microsoft actually stumbled across this competitive advantage. Anybody who thinks Microsoft had a vision couldn't be more mistaken. At the time, Microsoft was behaving very much like the Unix system vendors, doing very little to make DOS adapt to other files systems. It was the vendors of those other file systems that started Microsoft operating systems down the path of widespread network protocol and file system support. Virtually all of the original DOS drivers for standard and non-standard network protocols and file systems came from third parties. So, too, did the software that married those drivers to the most popular networking hardware (Ethernet, Token-Ring, and Arcnet). That same software also neatly tucked the results of the marriage behind a single drive letter (i.e., X, Y, or Z), making user access to those file systems a wee-bit easier than Unix.
Remembered as the C-prompt by many (but it was a different letter for each volume a user needed to access), the method of assigning disk volumes to letters--known as mapping--was an improvement over Unix's default for handling the same task. Any IT manager who's been around the block a few times can remember telling a user to just go to the "N drive" (the letter many network administrators chose to map DOS users to network servers). End users appreciated this abstraction, but never really understood what it took to make it work. They didn't want to, nor should they have.
Understanding this very simple customer requirement--to insulate end users as well as IT personnel from needing to know about the inner workings of accessing networked resources--is what helped Microsoft achieve the monopoly it has today. Ironically, while DOS's abstraction of file systems was just marginally better than that of Unix (a prompt is a prompt, right?), it was significantly worse than Macintosh's. Had Apple decided to license the Macintosh operating system early on--a decision that would have driven down the cost of owning a Mac--it might very well have found itself in Microsoft's place today. An even greater irony is that we'd all be using Mac OS X, the most approachable version of Unix ever.
Making DOS adapt to other network protocols and file systems turned DOS into the most flexible network client on the market. In combination with the low cost of DOS-based systems (relatively speaking), this flexibility set Microsoft operating systems up for the ubiquity they enjoy today. Not that some predatory practices along the way didn't help.
Achieving this flexibility however, wasn't easy. Adapting DOS, especially when multiple network protocols and file systems were involved, resulted in a precarious balance of operating system, applications, and drivers. So delicate was situation that it gave rise to an entire third-party industry of memory management software whose sole purpose in life was to keep DOS from crashing and users from losing their work.
The operating systems' flexibility, something which was obviously important to end users, was now threatening something that was even more important to customers: stability. At the same time, IBM's OS/2--significantly more stable and robust than DOS--was on the scene. It was time for the fittest to survive, and Microsoft had two choices. It could continue to depend on third parties to guarantee the stability of it's operating systems and the future of the company, or it could take matters into it's own hands. Based on the inability of third parties to deliver consistent results (which some argue was exacerbated by Microsoft's concealment of APIs) and the increasing complexity of supporting millions of users in highly unpredictable environments, Microsoft really had no choice.
Which pretty much gets us to where we are today. HTTP is basically just another file access protocol, and a standard one at that. It joins a long list of other file systems, both proprietary and standard, that any client operating system should expose via a single file-access interface. If Microsoft's bundling of this or any other functionality that gives end users, IT Managers, and developers a consistent way of accessing system resources makes it guilty of anything, then we might as well turn back the clock to revisit the old DOS and Unix shell prompts and the "type" and "cat" commands (the DOS and Unix equivalents for revealing the contents of a file) and condemn the whole lot of OS vendors.
In light of the government's recent decision, The DOJ is now reconsidering its position on Microsoft's future bundling practices. Internet Explorer will no doubt continue to face extreme scrutiny and possible remedies ranging from shipping the OS without it to making it uninstallable by OEMs and end users. Forcing Microsoft to make IE uninstallable--or any other part of the operating system that has evolved based on end-user requirements--is utterly ridiculous.
On the other hand, should Microsoft go so far as to disallow the installation of alternative solutions, then the DOJ must act. But to date, we are free to install alternatives for just about everything: browsers, file access utilities, video decompressors and viewers, and so on. The user interface should be flexible enough for OEMs and users to deactivate any unwanted button or icon, or to override many of Microsoft's out-of-the-box defaults (such as what application to associate with HTML documents).
End-users who choose to customize in this way can derive great satisfaction from their systems. But they will be equally happy when they place a call to Microsoft for support and get their problem solved because the predictable environment that Microsoft intended to deliver is still intact.
What do you think? Share your thoughts with your fellow readers at ZDNet TechUpdate's Talkback, or write directly to david.berlind@cnet.com.
Got a great tip? An industry rumor? Or do you want to submit your own column to ZDNet TechUpdate? Send David your submission, and if we use it, you'll be compensated with some of the cool vendor schwag that arrives in our mailboxes on a daily basis.
