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 BIOS—and 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:
ca@charlieanderson.com )
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:
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 cards—common
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 IRQs—it had only one
left to go around for both cards. The unlucky second card caused the machine to
either not boot—or if you were already booted up and stuck the
card in—you'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 all—a 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 1998—there 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.
