* The source of your patching problems
I’ve been rambling on over the past couple of issues, lamenting the seemingly endless rounds of patching needed to correct the apparently unending bugs and flaws in the Windows operating systems.
I was waxing nostalgic for the software in the pre-Windows era (the latter part of the 1980s, before Windows 3 was released), which I maintained was less vulnerable to security flaws, had fewer bugs and was more quickly fixed. A number of you pointed out that there was also very little Internet connectivity for DOS-based PCs, so the opportunities for viruses, worms and Trojans were fewer.
While it’s true there were fewer malicious attacks, the delivery mechanism for them was (adjusting for the paradigm of the day) remarkably similar. They came in two forms – e-mail attachments and downloaded software. Microsoft Mail had Internet gateways in the days before Windows, while many computer enthusiasts gleefully downloaded all sorts of stuff from computer bulletin boards.
But it isn’t the idea of security vulnerabilities that bothers me so much, as it seems to be impossible to stop them from occurring (or recurring). What worries me is that it seems that patching one bug or exploitable flaw simply opens up one or more new ones.
Last issue, I mentioned “programming by committee,” “eXtreme Programming” and other methodologies that purport to deliver software that’s more feature rich, can be brought to market quicker, and yet be more customer friendly than ever before. Balderdash! (I’d say something stronger, but this is a “family” newsletter. Most of my family read it, doesn’t yours?) Think of the major services, applications and operating systems you use. Can you say that you use most of the features of any one of them? No, you can’t. Anyone who believes they are using most of the features simply hasn’t discovered all of the bells and whistles the software offers. I seriously doubt that any one person at the software vendor is able to recall all of the features offered.
Twenty years ago, when Visicalc (the granddaddy of all spreadsheets) burst on the scene, Dan Bricklin (one of the two guys who created it – the other was Bob Frankston) knew every feature of the program. It’s possible he knew every line of code off the top of his head. If someone reported a bug – something that didn’t appear to work right – Bricklin knew immediately where to go in the program to fix it. That doesn’t happen today.
For something as massive as the Windows operating system release, I doubt there’s any one person who could even tell you who wrote the part, which might be the source of a problem you are having. Tracking down the right area to patch, as well as the engineer who could intelligently design that patch is a major undertaking.
