The PC Platform: Past, Present, and Future (1998)

Too Many Files

My current home machine (but certainly not my first PC), a Dell Pentium 200 ("with MMX!"), arrived in the mail from Austin in April, 1997.  It came with many hundred man-years of software development effort pre-installed.  I couldn't buy it any other way.  I could either get the "Home Essentials" bundle of Microsoft stuff, or I could opt for the "Microsoft Office" package.  Each consists of a half-dozen CD ROMs (a single CD can hold about 680 million bytes of data). 

In the year since, I've added some games, various development tools and SDKs, and subjected my hard disk to net downloads of all stripes.  (I swear, my Real Audio player is out of date no matter how often I install the latest.)

One year laterApril 11, 1998despite the fact that both the Internet cache and temp directories live elsewhere, the Windows directory of my machine's C: drive contains 4633 files in 235 subdirectories, occupying a total of 298 megabytes. This is the operating system directorythe place where Windows itself resides.  For heaven's sake, how can anyone, even Bill Gates, hope to maintain a system that consists of this many moving parts?

The Holiest of Holies, the System directory, contains a whopping 1492 files in 13 subdirectories, occupying 170 megabytes. Here's a partial breakdown:

bullet53     .OCXs  
bullet772    .DLLs
bullet81     .EXEs
bullet40     .DRVs
bullet74     .VXDs

Each of these files contain executable code and any might be the culprit when my system gets into its pet "Protection error.  System will now restart" mode at boot time (about every two months). 

What are these files, and what are they doing in my system directory?

Device Drivers

Prior to Windows, the PC platform featured a small, core commonality--MS-DOS, x86 CPUs, a reasonably predictable BIOSand a less predicable assortment of peripherals (printers, graphics cards, etc.).  It was up to each application to provide support for peripherals, and this was quite a burden. For example, when creating Quattro Pro/DOS at Borland, my group spent a lot of time worrying about oddball printers and plotters. This was time not spent on spreadsheet features. And every software company with an application that needed nontrivial printing had to do the same damn thing.  Many wheels were re-invented in this era.

With the rise of Windows, Microsoft took over the role of device support. They publish a two-sided API: one that application programs see, a second for device drivers. Device manufacturers write device drivers and give them to MS for testing and with luck, inclusion on the Windows 9x master CD, where the clever setup program figures out what peripherals the user has and what drivers to use to run them.  (The setup program for Windows 9x is not a program I would like to be responsible for.  A thankless, nightmarish task.)

By and large, this is a good thing.  Nowadays the details of printing are hidden from applications.  An application can do a pretty good job in 1998 printing on dozens of different devices without caring what manner of printer is plugged in on a given user's machine.  The Windows printing interface hides the details of the actual device. 

But device independence doesn't come for free.  There's a complexity cost paid by the operating system.  Device drivers need UI for selection and option tweaks.  The user has to run the UI properly.  The right files have to be where the UI can find them.  And the driver has to work; a buggy driver can bring down a machine.

The rocket scientists at Microsoft have a lot of work to do to improve the mess that is the Windows Device Driver problem.  The UI is often cryptic, and in my experience, lots of web surfing, downloading, and  good-old-fashioned-guess-and-reboot is required to make things work.  Most end users don't have a programmer's tenacity in dealing with such things. They get frustrated, turn off the computer, and go play golf.

OLE: Code Sharing

It was faddish in the early 1990s to believe that embedding and in-place editing would solve all software problems for all people.  If I saw one demo of embedded video running inside a word processor, I must have seen sixteen.  It was yet another answer to the how-to-reuse-code conundrum that has bedeviled programmers since the first loops began iterating within relay and vacuum tube machines in the 1940s.

The future, according to the OLE ("object linking and embedding") evangelists at Microsoft, would consist of dozens or hundreds of discrete applets, happily living inside whatever application wanted their features.  While certainly a worthy goal, as implemented OLE introduced a substantial complexity penalty to the already tricky world of Windows programming.  We'd probably have the handwriting recognition problem licked already if so many man-millennia hadn't been wasted on OLE.

The Registry

One of the lynchpins of the OLE/Shared Applet scheme is the Registry, primarily a repository of obscure facts stored by OLE objects.  Much of what's in the Registry of a real-world machine like mine (6.6 MB of stuff as of this morning) is inevitably wrong.  Drive names change. CD ROMs are removed. Files and directories are renamed, copied, and deleted.  OLE applets go to the bit-bucket, leaving dreamy dregs of their existence in the Registry. 

Shouldn't you be able to copy an application from one machine to another by copying the directory it lives in?  With Windows and its Registry scheme, this is seldom true. Some pieces of the application may be DLLs in a different directory.  And the registry on the new machine will be ignorant of the newly-copied application and whatever history the user had with the app on the other machine.

The Registry is a bad idea because it violates a key software engineering principle: keeping a fact in one place is almost always preferable to making copies of a fact and then making sure that the copies always agree with each other. The file system must be Ultimate Truth. If the file system thinks OLE server foo.dll is in directory oldbar, who is the Registry to say it's in directory bar?  Windows and Windows applications have to work hard in what is ultimately a losing battle to keep the Registry correct and relevant.  It would be cleaner to build a component database at boot-time from some set of OLE DLLs, perhaps all that reside in a special directory.  Individual applications can keep the factoids they need to retain between invocations wherever they want—the old .INI file scheme worked well.

Evolving Mission of the Platform

The world changes in ways that are impossible to anticipate.  In 1993 the Internet was a networked playground known and loved by a few bearded Unix programmers.   A mere five years later, web browsing had become arguably the most significant application for personal computers.  If Microsoft doesn't fully embrace the Internet, they risk Windows becoming obsolete.  Clearly, they aren't going to let that happen.  Is the browser a worthy "operating system" function?  I'm not a federal judge, but yes, I think so.  And in another few years, something else will appear and Windows will grow to embrace that.   (Incidentally, if you know what the next big thing is, please email me with details: )

Application Bundling

Bundling application software with new PCs helps the Dells and Gateways of the world sell machines (as if they needed any help). The software companies make a little piracy-free, cost-of-goods-free revenue (the cost of stamping a CD in volume is less than 25 cents).  The PC manufacturers can point to the hundreds or thousands of dollars of stuff the consumer is getting free. 

But I'd argue that bundling is not good for the software industry or the PC industry at large.  Customers get hard disks that are half-full right out of the box, redundant packages of CDs, and lots of apps they don't want or can't use (or both).   More importantly, they lose a sense of the value of software.  Software bundling devalues the bundled application, and worse, any competitor's application.  

Now that the market is huge, go ahead and sell those apps cheap, but don't give them away.  People don't value what they get for free.

What's Part of an Operating System and What's Not?

Where does the operating system stop and application software begin? This is a key legal, business, and software engineering question.

The term operating system used to refer to that software that buffers application software from the details of machine hardware.  Application software, then, is software that provides useful functionality—that makes the machine do something the user wants done.  Users don't want to manage virtual memory, write windowing systems, graphics primitives, or work with file allocation tables. They want to play games, write term papers, and browse the world wide web.

Not so long ago, the distinction between operating system and application was clear.  MS-DOS was a simple operating system comprising maybe two dozen files, of which two did 99% of the work.  CHKDSK.COM was part of the operating system; 123.EXE was an application. 

When the fantastic but flawed Apple Macintosh arrived in January, 1984, it broke ground on many fronts—one being the deliberate blurring of the line between operating system and application software.   The machine shipped with some nice apps, including MacPaint and MacWrite.  You couldn't buy a machine without them.  Apple had no choice.  They couldn't send an utterly new computing platform out into the world without providing something that new buyers could show their friends.

There was no disk in the box labeled "Operating System."  Rather, Mac users were encouraged to not notice where MacPaint stopped and OS graphics support started. 

When Microsoft shipped the ever-so-humble 1.0 release of Windows in 1985, they followed this example.  It included a simple paint program, a clock (analog—who says Microsoft doesn't innovate?), calculator, notepad, and so on.

But my, how things have changed in 13 years.  Window 98 ships with a vast amount of application software on the master CD, including:

bulletDisk compression software
bulletWord processing software
bulletVideo and Audio applications
bulletNetwork software
bulletInternet Browser
bulletEmail and Newsgroup Browser
bulletAddress Book software
bulletGame software

Microsoft releases new versions of Windows every few years, and since they want people to buy it, they continue to add additional applications to the mix.  Pinball games.  Disk compression tools.  Fancier calculators.  Multimedia players. And the list will grow further.  Woe to the independent software developer who chooses to write an application just like one that will one come for free on the Windows 2002 CD.

Windows, the operating system, should consist of far fewer files, and should keep those files in a directory that can't be contaminated by every Tom, Dick, and Harry piece of software that comes to live on a machine.  If you back up those files, you capture the state of your machine in an unambiguous, restorable manner.

The problem isn't just DLLs.  Windows needs fewer UI panels, fewer tricky shortcuts, fewer ways to do the same thing six different ways, and a lot fewer "throw it on the master CD, there's plenty of room" applications.  And it needs to be implemented with a lot fewer files.  If an application absolutely has to reside on that Windows 98 distribution disk, it should be clearly marked as an application and not part of Windows itself.   This is better software engineering and it might pacify the hounds at the DOJ as well.

Is NT the future?  Do you want a mainframe computer on your desktop?  Do you want to set user privilege levels on your own hard disk?  Do you want to become a system administrator for your personal computer?

Why Don't They Fix These Problems Before Adding One More New Thing

I recently had to send my two-month-old Dell Laptop back to the factory for a little R&R.  I took the precaution of removing my hard disk before sending the machine back.   (I had a good two months of application loading and general system tweaking invested in that drive and I didn't want to start over.)  When Airborne brought the machine back five days later, I plugged in the hard disk and it booted right up, and even ran under battery power, something it wasn't willing to do the previous week. 

I was just about to award Four Stars on the service survey postcard when I discovered that the machine had problems. If I plugged in both of my PCMCIA cardscommon modem and Ethernet cards, both of which had to be present for me to do my work, both of which worked before the machine went back to the factory, the machine wouldn't boot. I'd get to the Clouds screen, hear one beep, then a second, then a long, scary pause. Then the screen would go blank and another boot cycle would begin, and this one would drop me into the dreaded boot options screen.  A safe mode boot worked, but who can do anything with their computer in Safe mode?

As Apu at the Quickie Mart would say, What a puzzlement!  According to the paperwork, the factory replaced the system board, put in one that worked well enough to boot the machine and run my applications, just as long as both cards weren't plugged in.  Moreover, either card by itself worked fine, in either slot. 

What was wrong?  The new system board somehow didn't get along with my PC cards and/or the software on my hard disk.  After an hour of experimental rebooting, I determined that the system was out of IRQsit had only one left to go around for both cards.  The unlucky second card caused the machine to either not bootor if you were already booted up and stuck the card inyou'd crash.

Why? Because the CMOS settings on the new system board were subtly different from those on my old system board.  In the system setup program (that's the little text-mode jewel you race to get into by pressing F2 (or whatever) when the system first boots up), the built-in serial port setting was "Auto."  I changed this to "Disable," and suddenly the machine would boot up, because now there were enough IRQs to go around.

I don't know about you, but I think this is a pretty complex problem to have to troubleshoot. It meant that my system was doomed before the first bytes were read off the hard disk's boot sector.  The people at Dell service really couldn't be blamed.  They couldn't have anticipated that my cards wouldn't have worked or that I even had any PC cards.  And Windows gave me no help at alla message like "No free IRQ for the card in socket 2" would've put me on the right track immediately.  No, just a failure to boot with no message at all.

It's 1998there shouldn't be a CMOS setup program anymore.  There shouldn't be dependencies on  esoteric parameters rude enough to keep a machine from running.  And when are we going to finally be free of IRQs and port address conflicts? 

How many people can fix this kind of problem?  I'm a professional programmer who started working with the original IBM PC back in 1982, and I'm right at my limit.   I'd like to spend my time writing code and studying new APIs, not troubleshooting my machines. 


Back Home Up Next  •  Since 1998, Your Home for Charlie Anderson Information  •  Send me email: 

All Content © 1998-2002 Charles R. Anderson  •  This page was last modified on 11/13/2003