Notes

Software that achieves anything but the trivial is intrinsically complex and its manufacture is necessarily inexact. It is one of the contradictions inherent in software that although it is distributed on the mass-market scale of consumer goods, it is not so much manufactured as hand-crafted. Even in the most successful programs from the biggest software houses, bugs are inevitable and software consumers cannot reasonably expect a perfect product.

What software consumers may reasonably expect is frank admission to and open discussion of defects that the manufacturer knows to be present. Sadly, this simple matter of integrity and responsibility is typically too much for software manufacturers. Perhaps they think that honesty to consumers may harm sales or lessen profits. What is certain is that software manufacturers have the luxury of only rarely having to be honest. Consumers cannot easily inspect software to determine the truth of a manufacturer’s claims about a product’s expected behaviour, let alone the truth of a manufacturer’s explanations of unexpected behaviour. Even in the hands of expert programmers, techniques for independent analysis of computer software are simply not well enough established to be of any use in keeping software manufacturers honest. Sales and profits that might be harmed by honest disclosure of knowledge about defects have become sales and profits that software manufacturers take for granted as their due.

As if this is not bad enough, some software manufacturers lobby governments to make it unlawful for software to be disassembled, decompiled, reverse engineered or otherwise studied carefully, even for the purpose of assessing the truth of a software manufacturer’s representations about the software. Some governments show signs of going along with this. If you agree with the manufacturers, then don’t read on. Though I do not reverse engineer in the sense of trying to “recover” source code from which one might rebuild a product or copy its techniques into another product, pretty much everything that you can read here is the result of reading binary code in what may count in law as a translation to assembly-language mnemonics. Those mnemonics are just what are shown in a debugger and I maintain that I am just debugging in advance, but if you disapprove of my method of study or of my purpose, then do not use my results.

Bugs

As all programmers are only too well aware, many problems with software are caused by strikingly simple coding errors. The good news for users, who do not have the source code to edit, is that knowledge of a simple coding error often leads to one of two ways to deal with it independently of the manufacturer. One is to work around the coding error by operating the program in a slightly different way either to avoid executing the faulty instructions or to compensate for them. The other is to repair the faulty instructions by patching the executable.

Patching executables should not generally be welcomed, is already made difficult by advances in security (most notably for code signing), and may soon be impossible for some executables. Yet there are bugs for which there really is no better solution, especially because the manufacturer does not acknowledge the bug or will fix it only by the time-honoured abuse of leaving you to upgrade the software (for a fee, of course). It is conspicuous that in the list below, the bugs in the Archive section (from the late 90s) never did get documented by Microsoft as far as I have ever found, even though some of them definitely did get corrected in later versions.

The following exist specifically to report a bug, explain its cause, and at least suggest some sort of solution that does not require you to wait for the manufacturer:

Tips

Software often has features—sometimes even very useful features—that are not described in the manufacturer’s documentation, not just for ordinary users but even for system administrators or for those who pay extra for deeper technical detail.