Microsoft Still Baffled by UNIX
April 9, 2002
The site implies that because Windows is prevalent on the desktop, it makes sense in the data center.
Yet in one of the "research reports," a chart labeled "Important Issues That Drive High-End Server Selection" shows "reliability; stability; availability" as the top answer, at 53 percent.
"Easy to use; simple; familiar" is last, at 8 percent.
Doesn't seem like "desktop familiarity" is much of an argument for Windows over Linux. Such flimsy arguments are just the latest evidence that Microsoft (Nasdaq: MSFT) simply doesn't understand Unix.
It wasn't always like this. Microsoft used to sell a version of UNIX called XENIX. Consider the following quote from Paul Allen, Microsoft co-founder, in the 3rd issue of PC Magazine, June/July 1982:
"It's important to realize that MS-DOS is part of a family of operating systems.... Providing the user with a family of operating system capabilities means a clear migration path from MS-DOS to XENIX. That means compatibility for both the terminal end user and the systems programmer.... A standard library for XENIX-86 C will allow compilation of a program on XENIX ... and then execution on MS-DOS.... XENIX systems will be able to function as network file servers."
Microsoft had plans for XENIX back then, but over time, the plans evolved. First, the company was going to migrate users to OS/2, then Windows NT became the operating system of choice.
What changed? It's simple. Microsoft moved from command-line operating systems to Graphical User Interface (GUI) operating systems.
Migrating users from command line MS-DOS to command line XENIX seemed reasonable; but within Microsoft, UNIX -- with its command line origins -- everntually came to be seen as a step back from the graphics-based Windows.
Ironically, this command-line focus is one of the reasons UNIX is so compelling in the data center. (Modern UNIX systems all have GUIs, but much useful work is still done in a command shell inside a window.)
Command-line applications can be chained together using pipes, combined in a batch or script file, and easily run from a remote window on another machine. This is a huge benefit when the main administrative access to a rack-mounted computer may be over a serial port.
Gordon Bell, who led the development of the VAX architecture at Digital, came to talk to the NT group in April 1994. At the time, I was on the team, working on the second version of NT. Bell warned the troops to forget about OS/2 and Netware. If we beat Unix, Bell told us, we would easily defeat the others in the process.
Microsoft proceeded to ignore this excellent advice. While it bundled free software to interoperate with Netware, it did not include the equivalent software for Unix. The telnet and ftp daemons were weak. It made no effort to target UNIX the way it targeted OS/2 and Netware. This oversight allowed Linux to flourish, and damaged the IIS/Windows combo in its battle against Apache.
It wasn't the programmers' fault. While Microsoft was underplaying the powerful command window included in NT, the NT developers were using it for many of their day-to-day tasks.
While Microsoft was not shipping the standard UNIX utilities such as "grep" and "where," the programmers were using internal versions. The programmers understood the value of Unix; many had learned to program on UNIX machines in college before PCs became ubiquitous.
So what was the problem? For whatever reason, the program managers who design Microsoft software simply did not "get" the usefulness of command-line tools. These are not the kinds of people who write a makefile rule for every sequence of two or more tasks.
To them, it was inconceivable that anyone would prefer a simple command-line utility to a fancy graphical application. When programmers protested the lack of good command-line tools, the program managers told them they didn't understand the customer. And they infected the marketing teams with their biases.
As a result, Microsoft wasted chances to improve NT in the data center. For Windows 2000, Microsoft rewrote all the management utilities. But, rather than take the opportunity to make every management function available from a command-line utility, the program management team decided that every existing graphical utility should be rewritten to fit the new "Microsoft Management Console" architecture.
The result was a new set of management tools, different from what users knew, no more usable than before and just as GUI-centric.
So now Microsoft is struggling to get some semblance of remote administration support ready for the next release of the Windows server . And the people who design and market its software still can't figure out why anyone would use Unix.
Adam Barr worked at Microsoft for over ten years before leaving in April 2000. His book about his time there, "Proudly Serving My Corporate Masters," was published in December 2000. He lives in Redmond, Washington. Adam can be reached at: firstname.lastname@example.org.