This was originally posted on April 18th, 2001. While Java surplants most of this purely because machines have gotten bigger, I still stand by a lot of what's said.
I consult for a living, so I need to keep accurate track of the time I spend on multiple projects. There's a very nifty little utility for KDE that's useful for this sort of purpose called Personal Time Tracker (filename "karm"). The idea is simple... you list your projects, start the clock, and whenever you switch to a different task you simply click on the taskname, and the time accrues. At the end of the day you know exactly how much time you've spent on which project. GNOME has a similar utility (GtimeTracker), and there are some others.
Very nice, except these run on Linux. I do some work on Linux, but I also work on Windows and a number of other operating systems, (including DOS) so I thought I'd take an afternoon and code myself a more portable version of the program to use generally. I wanted a few improvements over the Linux programs as well, such as not having to have the program active in memory all the time, and being able to export to my spreadsheet. Here were my user requirements:
* I wanted it to run on any machine I happened to be around, including DOS clients without recompilation and without multiple versions.
* Since I move around between systems, I wanted to be able to put it on a floppy an carry it with me.
* Since I'd be carrying it on a floppy, it had to "work" even when it wasn't running(!)
* It should automatically save information when shut down.
* I wanted it to be extremely small so it would load fast. My arbitrary goal here was under 25kb.
* It needed to be able to export data to comma separated format so I could import it to my timesheet spreadsheet.
* I'm the only user, so the user interface didn't need to be slick and commercial.
(I might have written it to run under PalmOS, but quite frankly, having used one for awhile, I find the synching more cumbersome than the floppy. Shortly after writing mine I actually found a PalmOS equivalent and my prejudice held true.)
Given the requirement to "write once, run anywhere," I immediately thought of Java. However, I ran into a few simple realities. A Java Virtual Machines take up a lot of memory. They also take up a lot of disk space, and they take a long time to load. The most surprising reality, though, is that Java's not available everywhere. For instance, I still support a number of networked MS-DOS and DR-DOS machines, with 8MB RAM, of even 4MB RAM or less. I'll simply point out that there are only two DOS JVMs that I know of, Sun's JavaPC and Transvirtual's Kaffe, they both require a huge amount of memory, and neither of them is free. So Java wasn't a solution for me at all.
Without spending a LOT of time on it, I looked at a number of other alternatives, such as TCL/TK. But when the smoke cleared, I finally chose... DOS.
Why DOS? Basically, because (surprise!) DOS is more portable than Java for my purposes. My 1.0 program, weighing in at under 30K, operates on my DR-DOS powered laptop, on any Windows machine (Win9x or NT) or under any OS that can run a DOS emulator. For instance it runs under Linux's DOSEMU or VMWare, under OS/2, or on a Mac or Amiga with a DOS emulator. Even the most basic DOS emulator seems adequate, and the worst of them takes up less memory and disk space than Java. The choice of compiler was trivial (I used Asic, but there's no lack of efficient compilers for DOS) and I finished the program, from requirements to compilation, in one afternoon.
The important part of this exercise has nothing to do with the program I wrote: it has to do with the lessons learned. I began the exercise with the assumption that I'd be coding a Java program. However, the requirements that fueled Java's creation and have been fueling Sun's marketing are the very same requirements that prevented me from using Java. On the other hand, the much maligned and forgotten DOS turned out to be the best choice for this particular job... a simple, surprisingly portable OS for a simple application.
We tend to focus on the cutting edge of technology, with the unspoken assumption that the cutting edge is best. Sometimes that assumption isn't warranted (for instance I don't foresee the wheel being replaced by magnetic levitation on a large scale basis in my lifetime and the basic design of a hammer hasn't changed in 20,000 years). DOS is still alive in embedded systems, where the the task to be performed gets better press than the technology behind it, and I'm convinced that its relegation to obsolescence is premature.
Hmm. I wonder what other perfectly good technologies we are throwing to the wayside before their time?