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.

Good points

• Standard user interface. Before Windows, every application had its own user interface conventions. For example, to make a specific action happen, some used control keys, others used function keys, yet others had "modes" where ordinary letters meant "do something" instead of filling in text on a field, etc. When you first tried to use a new program you had to not only learn the general philosophy of the user interface; you also had to learn all the details. Windows came along and changed all that. It provided a set of user interface "controls" like text boxes, command buttons, check boxes, list boxes, etc that a programmer could easily incorporate into his own program. Now when a user comes to a new program, he should be able to at least understand the user interface: he immediately knows that clicking on a command button should make some action happen, how to select from a drop down list, and so on.
• Consistent printer interface. By the time Windows came out printer capabilities were exploding: At one time printers printed text, period. There was no need to specify font style or size or bolding, because the printer only had one font style and size, and the way you got "bold" was by overprinting the same text. Graphics? Yeah, right. But as all these capabilities were added, you had to have a way for the program to tell the printer just how it wanted the printout to lookl. Each printer had different ways of specifying this. This was great for users who wanted pretty output. It was a nightmare for programmers. Every program had to know how to control every printer. What if the user had a model of printer that the programmer never heard of? What if a new model printer came out after you published your program? Some companies made a living just building lists of all the different printer control codes and schemes.

  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.

• Dynamic file selection. A Windows program can easily accept the name of a file from a user and then read and write from this file. The programmer does not have to have any clue what files the user might want to use at the time he writes the program. Indeed, a program can even generate a file name dynamically at run time, for example, it can generate the name of an output file from the name of an input file (such as changing the extension), using all sorts of fancy string manipulation if you choose.

  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.)

• True multitasking. (Since Windows 95.) Multiple programs can run at the same time without the programmer or the user having to go through any complicated gyrations. This was most definately not true in MS-DOS and other early microcomputer OS's, where the programmer had to trick the OS into keeping two programs loaded at the same time. This is a good and important feature, but I don't give Microsoft a lot of credit for it either, as plenty of others were doing this before Windows came along, and Unix and Linux still do it better.
• The Clipboard, also known as cut, copy, and paste. Windows provides a place where data can be temporarily stored. Applications can copy data to the clipboard without knowing anything about the application that will retrieve it, and applications can retrieve data from the clipboard without knowing anything about the application that put it there. It provides four useful standard formats that many applications can use: plain text, rich text (text with formatting information like font style, italics, etc), raster graphics, and vector graphics. Okay, the vector graphics format is of limited value because it provides only a small subset of the capabilities that vector graphics programs typically provide, but the other three are quite capable, not because they have a lot of features, but because they were carefully constructed to require only a minimal set of features to do the jobs. For more complex cases, programs can freely add their own formats to the clipboard.

  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.

Bad points

• Complicated application programming interface (API). The documentation on the Windows API runs to several thousand pages. If there were just so many capabilities that there was no way around this, perhaps we'd just have to accept this. But the API is filled with multiple redundant ways to do the same or similar things, and incredibly complicated ways to do simple things.

  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.

• The Registry. This was such a stunningly bad idea I don't know what was going through their heads over there in Redmond when they invented it. Control data for every application on the system is thrown into one big file that is not only difficult to view and manipulate, but if you try to and make a mistake you could trash your entire system. It is virtually impossible to manage.

  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.

• Security. Windows security system is messy, difficult to administer, and not very secure. Compare it to the elegant simplicity of Unix: In Unix, each file is owned by a user and a group. By default, the owning user is the user who created it, and the owning group is the "primary" group of this user. The file then has three sets of permissions: one for the user, one for members of the group, and one for the rest of the world. Each set says whether you can read, write, and/or execute. Additionally, you can specify that when a program runs, it runs with the privileges of the owner rather than of the user who is running it. (Directories have the same permissions as files, with some reinterpretation.) There is a file that lists all the users and another that lists the members of each group. Simple, secure, and effective. What Unix does with three sets of three permissions Windows does with dozens or hundreds of sets of six "basic" permissions plus I-don't-know-how-many "advanced" permissions. Windows must give at least half the functionality with only ten times the complexity.

© 2004 by Jay Johansen

Comments

No comments yet.

Add Comment

Name
E-mail
Comment