by Jay Johansen | Mar 18, 2004
It's always easy to criticize other people's work when one has the benefit of hindsight. On the other hand, I think it is quite fair to find fault when someone does things wrong despite the fact that there were others around at the time doing things right. In any case, we can evaluate someone's work without necessarily ridiculing them for every mistake. So here are some thoughts I've been mulling on the good and bad points of Microsoft Windows.
This is written primarily from a software developer's point of view, and secondarily from a user's point of view. I am comparing Windows to other operating systems that are or were available at the time. Necessarily the comparison is limited to OS's that I am familiar with, namely Unix, MS-DOS, CPM, TRS-DOS, SVS, MVS, and a few little microcomputer OS's that never made it big like Commodore DOS and ZDOS. The biggest obvious omission in any comparison is Macintosh, but I don't have enough experience with Macs to say much intelligent about them.
Windows provided a radical solution: It offered each application a single printer interface and it offered each printer a single application interface. An application does not talk directly to the printer, instead, it tells Windows what to print, and Windows tells the printer. For example, there is a single Windows call that says "text that follows should be in italics" and another that marks the end of italics. That's all the application has to know. Windows knows how to print italics on every possible printer. Of course the printer manufacturer has to supply a "printer driver" that tells Windows how to use all the features on this printer. With other OSs, if we had, say, 100 applications and 20 printers, we had to have 100 x 20 = 2,000 application-to-printer interfaces. With Windows we just need 100 application-to-Windows interfaces and 20 Windows-to-printer interfaces, or 100 + 20 = 120. Much less total work.
Admittedly, a possible drawback to this scheme is that if a printer manufacturer invented some feature that Windows doesn't know about, it might be difficult for any application program to use it. A printer driver can include a "printer preferences" window to ask for selections that apply to an entire print job, so it was no problem when, for example, photo-quality printers came out that had to know whether you were printing on plain paper, glossy paper, etc. But if a printer wanted to give the option of, say -- and I'm just making something up here -- using a flat ink for some parts of a picture and a glossy ink for other parts -- there's just no way to convey this to Windows. Perhaps this capability had to wait until printer technology had matured to the point that there was a stable set of capabilities.
I don't give Microsoft a lot of credit for this, as Unix, CPM, and others were all doing this before them. But it is a stunning improvement over IBM mainframe operating systems, where all file names were hard-coded in the "job control language", outside of user control. The best you could offer your users was the ability to pick from a list of pre-programmed file names. (In later versions they added "dynamic file allocation", so it at least became possible to do, but it was still complicated and clumsy.)
This simple but powerful feature makes it easy for users to transfer data between applications. Incredibly, the authors of the applications don't have to even know that each other exist! And in many cases, all of this is supported while requiring exactly zero lines of code to be written by the programmer -- just use the standard controls and it magically works. The only time I've ever written code to support the clipboard was when I wanted to do something odd or complicated, like letting the user copy entire rows out of a table. Somebody at Microsoft had a stroke of genius on this one.
Example of redundancy: There is a set of API calls called Dynamic Data Exchange that can be used to pass information from one program to another. Then there's DDEML which is a whole new set of calls to do the same thing, which is built on top of DDE. Then there's COM which is an entirely different way to do the same thing. COM was advertised as the "new" way that superseded the kludgy old DDE, but to this day Windows Explorer used DDE to pass parameters to applications. Example 2: ODBC provides a standard interface between a program and a database. So does DAO. So does ADO.
Example of unnecessary complexity: Suppose you want to write a program that runs in the background -- invisible to the user -- and that makes some service available to other programs. In Unix, this is easy: You write the program just like you would if it ran in the foreground, and then when you execute it you type an ampersand ("&") after the program name. Simple. In Windows, you have to make it a "service", which means you have to write it using a whole "service API" and an entirely different structure from a foreground program.
May I suggest a stunning obvious alternative? Create one file in the system directory that records the location of every installed application. Each application is expected to add one line to this file, that contains the name of the application (or perhaps two names: a short name for internal use and a long name to display to the user), perhaps the version number, and the path to the primary executable for that application. Create a second system file that lists extensions and associated applications. Windows could provide a couple of calls to be used by the installation program that update these two files. The format could easily be made simple enough that an install program could open these files itself and make its updates: Updating the first one simply means appending one line to the end of the file. The second is a little more complicated because you may have to decide whether to override a previously-made association. The format could and should be made simple enough that a moderately sophisticated user could open them with Notepad and fix any problems. Any other information an application needs, the application is expected to store in its own data files. To encourage consistency, Windows could provide a standard set of calls to manage a preferences file, like the old Windows "ini" file interface or a Java properties file. Applications should be encouraged to store their preferences file in the same directory with the executable.
© 2004 by Jay Johansen