Software can be made pretty reliable, lots of people and companies know how to do so. The auto-pilot on an airplane comes to mind, as do the computers that run financial markets. Then there's mainframe computers, perhaps the classic example of reliability (I spent many years working in a mainframe environment). But chances are that the computer you are reading this on is not as reliable as it could be.
Let's start with an analogy. How would you feel if you were in a restaurant, in the middle of your meal, and the waiter takes your food away? It's a breach of the rules; food isn't supposed to be removed while the customer is eating.
Windows XP is that waiter. It lets you delete a file while an application is using it.
I ran into this recently while viewing an image with the popular IrfanView program. I was cleaning up files and deleted some pictures only to realize later that IrfanView was still running, minimized in the taskbar, and viewing one of the just deleted pictures.
This should never be allowed to happen, and it doesn't on a mainframe.
Windows knows full well what picture IrfanView is using. IrfanView didn't scan the sectors on the hard disk by itself to figure out which ones constitute the picture. It asked Windows to grant it access to the file. But when it comes time to delete a file, Windows has amnesia.
IrfanView is only one example. Windows XP will delete pictures while they are being used by a running copy of both Paint and the Windows Picture and Fax Viewer too.
Adding insult to injury is that Windows makes the opposite mistake too. Many times when I'm finished using the files on a USB flash drive, the Windows "Safely remove hardware" function won't let go because it thinks one or more of the files are still in use.
Open a file in WordPad. Then open the same file in Open Office. Now both programs updating the same file at the same time. How come no one at Microsoft ever saw this as a problem?
To be clear, the gripe here is about Windows XP, not WordPad or Open Office. The operating system is in charge of the files. It has the responsibility for integrity, so it should not allow two programs, any two programs, to update the same file at the same time. Anyone with a database background knows what comes next.
Open a plain text file with Notepad and then open the same file with AbiWord (again the specific applications are not the issue). Make a change to the file with Notepad, save it and close Notepad. Open Notepad again and you will see the change that it just made. Now make a change with AbiWord and save the file. The change that Notepad made is gone. Disgraceful.
There's no gloating in Linux land either.
In a virtual machine running Ubuntu 7.04, I double-clicked on an image and opened it in the default application, Eye of Gnome. Here too, I was able to delete the image while viewing it. I also tried opening an rtf file in Open Office v2.2. Again, I could delete the file while an application was using it.
Ubuntu fared no better with multiple editors. I was able to open a file in both gedit and Open Office v2.2 at the same time. Changes made in gedit and saved, were wiped out by later changes made in Open Office. Just like Windows XP.
This brings to mind my initial experience with the Java programming language back in February of 2001. The first thing I did was to write a simple program that added two numbers and printed the result.
To explain why I chose this as my first Java program, let's suppose that all numbers are limited to a single decimal digit. Then, if you add 1 and 1 you get 2. But, if you add 4 and 8, you should get an error since the result is larger than a single digit.
Along these lines, Java has a numeric data type called "integer" which is used for integer numbers up to 2,147,483,647 (let's call it 2.1 billion for the sake of argument). In my first Java program, I added two integer numbers and stored the result in a third integer - the code is below:
This adds 2,111,000,333 and 1,000,222,333. The result--roughly 3.1 billion--is too large to fit in an "integer" variable. I wanted to see how Java handled this. The result was:
Not only is the answer wrong, but Java didn't crash, as I expected it would. Mainframe programs crash when they encounter this type of error - better to fail than produce wrong results.
Java didn't even issue an error message.
Update: October 22, 2007. I was asked by CNET if the above Java issue still exists. It does. Using Sun's JDK version 1.6.0_03 on Windows XP, I was able to re-create the problem. A screen shot is below.