Coda on “Microsoft Turns 35”

Preston Gralla, at ITworld.com wrote a blog about Microsoft Turns 35.  About the subject, we’d quote the Vice President [speaking “off the record” on the health care bill] here, but this is a family blog, so I won’t. Anyway, Preston’s article about the successes and failures of what the Unix Curmudgeon fondly calls “The Redmond Menace” skimmed over a few milestones and features, being mostly non-technical in nature.

Of course, it is fairly well known that Unix predates Microsoft by five years: the Unix Epoch, which is also the time system used on the Internet, starts on January 1, 1970 (GMT, so that zero-time in the United States is always sometime in afternoon or evening of December 31, 1969, thus explaining those SPAMS you get dated 1969–the forged emails have no timestamp, so your mail system puts in “zero” for the “sent time.”)  What isn’t so well known and wasn’t pointed out in the article was that, for a time, Microsoft licensed a version of Unix called Xenix, written for the Intel 80286 microprocessor, which could access more than 1MB of memory and had a protected mode to provide kernel security. Microsoft didn’t directly market Xenix, but sublicensed it to the Santa Cruz Operation. What Microsoft did do was to “borrow” some of the concepts [but not the code–that would be “software piracy,” something that Microsoft has vowed to eliminate by making sure every computer on the planet has a paid-up Windows license] from Unix to incorporate in MS-DOS 2.0.

MS-DOS 1.0, as mentioned in the referenced article, was essentially a 16-bit reverse-engineered clone of CP/M and wasn’t very extensible, especially in handling file systems on large disks, since CP/M was originally an 8-bit floppy-disk program loader, and IBM wanted to add a 5-MB Winchester hard disk to the PC. Subdirectories came from Unix, but Microsoft retained the drive letter designation from CP/M, and reversed the directory level separator, using a back-slash because CP/M (and DOS 1.0) used the forward slash for command-line options and, then as now, backward compatibility was a primary goal, even if it perpetuated bad ideas and awkward constructions. Since the Internet was developed out of Unix networking, the Web uses the Unix conventions, which causes confusion between Windows native file paths and web paths to this day.

Of course, CP/M came along about 15 years into my IT career, and was the system on the first microcomputer I used at work in 1981. In the prior age, when we wrote computer programs, each program was self-contained, and the computer only knew how to read the first file on the tape.  The idea of CP/M, a universal front-end for loading and interfacing with microprocessors, that would load other programs and handle input and output, had a lot of promise, and made it easy for companies to write programs that would work on any computer that had a compatible processor and CP/M: I even attended the big CP/M ’83 conference in San Francisco where the latest database, spreadsheet, and word processing programs were rolled out, still doing rather remarkable things on 8-bit microprocessors. But, by the end of the year, MS-DOS and IBM had cornered the big business market what was essentially a 16-bit reverse-engineered port of CP/M, and CP/M itself was relegated to the dustbin of history. My first MS-DOS machine at home, in late 1985, ran MS-DOS 4.0, which was, as stated, buggy and was missing a lot of the capability added by MS-DOS 5. A couple years later, I installed Windows 2.0/286, which was terrible, compared with the Digital Research GEM (Graphical Environment Manager) that was used as the front-end, under MS-DOS, for a lot of graphics programs in the mid-1980s, and no match whatsoever for the Apple Macintosh, which, like Unix, was a true multi-tasking operating system under the similar graphics. Both GEM and Macintosh were inspired by the Xerox Star graphical user interface developed at the Palo Alto Research Center, and Windows was inspired by the need to kill Apple at all cost (GEM was killable by virtue of being an MS-DOS application that simply wouldn’t run with Windows). Windows was little more than a slow, low-resolution, limited-color task switcher, and few programs were written for it because the programming API was a mess that took months for an experienced programmer to master.

But, since I had an 80286 computer, I could run a real operating system on it, instead of the Microsoft abomination. Xenix, since royalties flowed through the Santa Cruz Operation to Microsoft to AT&T, was extremely expensive, but a decent Unix clone based on System 7–the last in-house version before the deregulation of the telephone monopoly Bell created AT&T and allowed them to market Unix commercially–was available for $99. So, I ran Coherent–for years. It not only ran multiple programs concurrently, but we bought a few text terminals at a swap meet for a few dollars each and the whole family could use it at the same time–it was multi-user.

With the introduction of the 32-bit Intel 80386 microprocessor, which could run standard Unix, SCO broke out from under the thumb of Microsoft and released SCO Unix, letting Xenix die the death it deserved (the 16-bit computers had a 64K data segment size limitation, something that we also had to deal with in Coherent). At home, we finally retired the 80286 and jumped directly to an 80486 when Coherent was ported to 32-bit. By then, Microsoft had released Windows 3.1, which actually had some usable capability, though it was, like GEM, little more than a graphics manager that loaded on top of MS-DOS, and was still 16-bit. But, IBM and Microsoft were building a real[tm] 32-bit operating system, OS/2. Although Unix (Coherent) was the workhorse system at home, I needed to develop MS-DOS and Windows applications, so I bought another computer and immediately installed OS/2 on it. OS/2 was rock-solid and performed well, running Windows programs as well as native code. But, because of the split between IBM and Microsoft, when Microsoft released their own 32-bit operating system, Windows 95, OS/2 could no longer run programs written for Windows 95, and it simply died.

Even mighty IBM was not immune to the wrath of the Redmond Menace–a company that, time and again, exhibited a ruthless policy to either absorb or destroy any possible competition. The easy targets were, of course, companies that depended on Windows and MS-DOS as an operating platform. Apple and Unix continued to survive and even flourish, though their market share percentages shrank as Microsoft swallowed the world with their draconian licensing policies that made it impossible to build a computer capable of running Windows without paying for and installing Windows on it. All of us running Coherent, OS/2, and, later, Linux, not only paid Mark Williams Company, IBM, or one of the Linux distributors–Slackware, Debian, SusE, Red Hat, or others–for a usable system and support, but also paid Microsoft for a useless system to throw away. This means, of course, that, though Microsoft claims more than 90% market share, based on PCs sold versus Macintosh sold, a substantial percentage of those computers shipped with factory-installed Windows are actually now Linux computers. We try not to contribute to the Microsoft market share (or their already-bulging coffers) by building our own Linux computers from spare parts, but, of course, these don’t even show up in the numbers because they weren’t sold as complete systems.

Time will tell whether Microsoft will survive to see 50.  Their flagship system, Windows, has evolved slowly, through blunders and misguided attempts to layer new concepts on top of dead-end designs, layers that have added complexity to the programming and management of the systems, so that turning the juggernaut onto a new track may be nearly impossible.  Apple solved their transition into the 21st century and second quarter century of existence by porting their trademark user interface onto a solid, standard, and open operating system–a version of BSD Unix named Darwin, though it results in one of the stranger flavors of Unix to administer.  I can’t see that happening with Windows–it is just too alien and too convoluted to fix by running it on top of Unix.  Rewriting the NT kernel one more time to fix the security issues from the bottom up instead of the top-down weekly and monthly and emergency band-aids Windows users are subjected to would be a massive undertaking, and we’ve seen 10 years of effort since Windows 2000 to get what seem to be minor refinements and even some major setbacks, with the Vista fiasco as a prime example.  And, with the improvements in automated installation of Linux and the renewed visibility of Apple in the music and phone marketplace, users know they have a choice, and don’t have to endure years of frustration in hopes of getting a system that works to replace the one they have.