The importance of error code backwards compatibility
I remember a bug report that came on in an old MS-DOS program (from a company that is still in business so don’t ask me to identify them) that attempted to open the file “”. That’s the file with no name.
This returned error 2 (file not found). But the program didn’t check the error code and though that 2 was the file handle. It then began writing data to handle 2, which ended up going to the screen because handle 2 is the standard error handle, which by default goes to the screen.
It so happened that this program wanted to print the message to the screen anyway.
In other words, this program worked completely by accident.
Due to various changes to the installable file system in Windows 95, the error code for attempting to open the null file changed from 2 (file not found) to 3 (path not found) as a side-effect.
Watch what happens.
The program tries to open the file “”. Now it gets error 3 back. It mistakenly treats the 3 as a file handle and writes to it.
What is handle 3?
The standard MS-DOS file handles are as follows:
|3||stdaux||standard auxiliary (serial port)|
What happens when the program writes to handle 3?
It tries to write to the serial port.
Most computers don’t have anything hooked up to the serial port. The write hangs.
Result: Dead program.
The file system folks had to tweak their parameter validation so they returned error 2 in this case.