|Stories: Operating Systems|
|These are stories about operating system quirks.|
On an IBM mainframe (at leats when I used to work at GTE Laboratories), making even tiny changes can be quite complicated. The system doesn't have any built-in flexibility for using new hardware. When you install something new, you need to regenerate (regen) the operating system to let it know about the changes. Windows is usually better: you only need to install new device drivers and reboot. PDAs are better still: you just plug in the new hardware or software and the system is ready to go, usually without shutting down or rebooting.
|New Paper Basket? Regen System|
Making hardware changes to MicroVAXes like the ones we used is relatively easy (assuming you know what interrupts and memory addresses to use). It's similar to the procedure for installing a device on a Windows PC.
Once while we were installing a new printer basket to catch printouts on one of our MicroVAXes (this was about as hard as replacing a mouse pad and didn't require shutting down), I joked to my boss that we should notify the Computer Center so they could regen the mainframe. He laughed and, after a little thought, pointed out that you might actually need to regen the mainframe to change a printer basket. Some mainframe printer devices ring a bell and wait for operator intervention when the printer basket is full. The operator removes the printouts and presses a key to let the computer know it's okay to continue printing. If you changed the size of the basket, you might need to regen to tell the system how many pages it can print before needing assistance.
Later my boss did call the Computer Center to tell them we had changed printer baskets. They were not amused.
This is a typical story about trying to fix a simple problem with Windows. I logged in, checked my email, tried to shutdown, and Windows 98 hung. It seems to do that more often when I don't disconnect from my DSL modem first (what if turning off your car with the radio running made the engine fall out).
|Shutdown Normally Next Time, Idiot|
Naturally when I rebooted the system gave me its insulting message "Shutdown Normally Next Time, Idiot" although it was the system that had forced the bad shutdown. While checking the hard disk, the system discovered that one of the system files was corrupted so it replaced it with a previous version. Very gracious of it considering it had corrupted the file in the first place.
Everything seemed fine for a day and then suddenly Windows Explorer stopped displaying folders in the TreeView display in the left pane. When I double clicked on a folder in the right pane, it launched a new folder display to show it with big icons. No amount of configuration could make the left pane display anything useful, make Windows Explorer show the new folder in the same window, or make the new folder default to a display other than icons.
After a couple hours of fruitless searching Microsoft's Web site and the Web, I couldn't find anything about this problem. Eventually I guessed that the file that had been corrupted might be mscomctl.ocx, the file containing the TreeView control. I decided to download a new version so I wasted another half hour searching Microsoft's Web site for that file. Considering it's a freely distributable OCX you would think it would be a little easier to find. I found lots of copies on the Web but none were at Web sites I considered completely safe and I wasn't sure what versions they were or what version I needed.
Finally, in an act of desperation, I went to Microsoft's Web site, installed Internet Explorer 6.0, and voila! Internet Explorer 6.0 seems to have updated mscomctl.ocx (or whatever the problem was if it wasn't that) and Windows Explorer now works once again.
When I started programming professionally, some operating systems were more reliable than others.
- A typical PC could run for several days without crashing.
- The Unix systems at GTE Laboratories
where I worked could run for a couple weeks without crashing. I think most of the time
they were brought down it was because the system managers were messing with them.
The Unix system manager mentality was pretty much, "If you want to play with the system, go ahead."
- Sun specifically recommended that its customers reboot their systems at least once per day
to clean up memory leaks.
We were running VMS on MicroVAXes. Our machines ran for years at a time without rebooting!
They literally never went down except for power failures (before we got our UPS) and when
we needed to bring them down to install new hardware.
These days, my Windows operating system typically shows me the Blue Screen of Death at
least once per day.
Not all that long ago, Apollo was one of Sun's main competitors in the high-end workstation market.
They later got eaten by Hewlett Packard.
In those days, there were two main focus models: click and real-estate. In the click focus model,
you click on a window, it pops to the top, and it gets focus. This is the way Windows works and
at this point I think most people are using it. In some versions of XWindows and Motif,
you could Control-Click a window to give it focus but keep it in the background. This was useful
if you wanted to copy information off of another form, but I guess Microsoft didn't see the point.
In the real-estate focus model, the window with the focus is the one under the mouse. If you moved
the mouse over a window, it automatically pops to the top and gets the focus. No click required!
One annoying feature of the real-estate model is if you are happily typing away and you bump the mouse,
focus may switch to another window and your typing gets dropped there. If you are lucky, that window
does not accept the text and you lose your typing. If you are unlucky, your key strokes send the other
application into apoplectic fits!
Despite its "obvious" drawbacks, lots of programmers (particularly those using Suns and some other Unix-based workstations)
got used to the real-estate model and would defend it to the bitter end.
To make a bad story worse, for a while Apollo workstations used single cursor for both text and the mouse.
If you moved the mouse, the text insertion position moved.
Imagine yourself typing happily away when you bump the mouse. First the characters you are typing
get scattered across the window in which you are typing. Then the mouse leaves that window and you drop
characters in random parts of other applications. Best of all, if the mouse wandered over the desktop
so there was no application to catch the keystrokes, the system crashed.
To solve this problem, a lot of developers would carefully position the mouse where they wanted to type.
Then they lifted the mouse up, turned it upside-down, and placed it on top of the compuuter's monitor.
That way the mouse wouldn't move even if the bumped the table.
What a wonderful system!
By Colin Day.
I bought a VB add-in that includes a library of useful code snippets and
routines. It is implemented with a tree control to navigate to the
category you're interested in and select the routine that you want to
see. Mine would never work. The code was all sitting there in the
database but I couldn't see the routines in the tree control.
Suspecting database problems, emails went back and forth between myself
and the developers suggesting reinstalling ADO and MDAC and that sort of
thing. Nothing helped.
Eventually, unable to recreate my problems and with thousands of working
sites worldwide, they sent me the source code to have a look for myself.
The code snippets are held in the database with numeric keys, but of
course that won't work with a tree control, so the developers prefix the
keys with a letter before adding them to the control, "C" for categories
and "R" for routines. This was failing, but not being trapped.
It was failing because ... wait for it ... our currency symbol here in
South Africa is "R" for Rand and values like "R1" are considered by VB
to be numeric! Now, who'd have thought of that! I changed the prefix
for routines and ... Hey Presto!
Lessons Learned: Don't suppress error messages with On Error Resume
Next (if it can never happen ... then it's sure to!) and watch out for
internationalisation, it's all around you quietly doing it's stuff.
[Developers often ask, "Why should I use 'On Error GoTo 0' to disable error handling when I'm done catching a specific error?" Here's a good example. See also my book Bug Proofing Visual Basic. -- Rod]
|If you would like to contribute a story, email me.|