With Windows, the message is the medium. (computer programming) (Column)
by Tom Campbell

I've bee involved with Windows on and off since before version 1 was released, although not as a programmer until recently. My first encounter was on the technical team of a Macintosh database project that was considering a port. We had a state-of-the-art IBM XT, with a stunning 512K of memory, a giant 10MB hard disk, and the still-acceptable Hercules car for graphics.

The Windows development system was everyone's first brush with C, and we were shocked at how crude the programming environment was compared to the Mac's truly elegant Pascal development system. We were also among the very few people even to this day who weren't shocked and dismayed at how complex a programming challenge it was. Yet I've never seen an overview article that described--from a programming standpoint--just how staggering a change Windows is compared with DOS.

Messages, Medium Rare

The message is the medium: If you've read it once, you've read it a million times. GUIs are the wave of the future. GUIs, like Macintosh System 7 and Windows 3.0, are object oriented. Well, that's not quite true. Let's get som terms straight and cut to the heart of the programming matter while we're at it.

First, remember that there are something like 50 million DOS machines out there. Second, note that while about 4 million copies of Windows have been distributed, that doesn't mean they're in daily use. Many of these copies came free with new machines. Finally, keep in mind that DOS does the job for millions of people and spending $2,000 to upgrade their machines to the 386X and four megs that Windows requires won't give them a commensurate increase in productivity.

And it might just do the opposite, since those few applications that exist in both DOS and Windows incarnations almost always look like completely different programs. That means that retraining poses a time-consuming and expensive problem. Yes, GUIs may be the wave of the future, but for now, DOS is a firmly entrenched standard.

As far as object orientation goes, the press has confused the nearly tangible feel of the user interface (menus, like folders, and so on) with the programming techniques used to write applications for it. This probably goes back to Small-talk (well known as the granddaddy of Windows) and the Mac Finder, which was indeed both a visually oriented graphical user interface and the archetypal object-oriented programming system.

Learning Centres

Nonetheless, programming and using Windows is fun. If you plan to do it in a "real" language such as C, C++, or Turbo Pascal, you've got to know up front that you'll spend at least six months becoming familiar with Windows programming issues. Maybe even a year.

You could program in Tool-Book or Visual Basic, but neither of these languages has what it takes to be a complete Windows language. If you choose an object-oriented language like Turbo Pascal or C++, chances are overwhelming that you'll need to know that language's object paradigms even before you read the Windows programming tutorial. You'll also need to spend an extra $60-$100 on reference materials, unless you already own the Microsoft SDK for Windows.

No other programming system on the market has adequate Windows reference documentation. And unless you're either dirt poor or merely self-destructive, you'll need to meet regularly with other Windows programmers to learn things you missed in the manuals (or, more likely, that the manuals failed to mention). CompuServe is a good place; plan to spend a minimum of $50 a month in online time if you join.

Pointers and Handles

When you write a Windows program, you must know that the message is the medium, to make the inevitable cheap joke at Marshall McLuhan's expense. Your program, if it's to look like any other program, is seldom in complete control of anything. Instead, it's constantly reacting to messages sent to it by Windows, other Windows programs, and sometimes even itself.

Your program has to be ready to quit automatically when the user shuts down Windows, redraw any of its screens when the user decides to resize the main window, and let go of just about any piece of memory it can get its hands on.

The simple act of writing to a dynamically allocated piece of memory (for example, copying the contents of a string into a buffer) means that you have to lock that piece of memory for only as long as it takes to write the value and then unlock the memory as soon as possible--whereupon the memory manager is free to write that piece of memory temporarily to disk so some other Windows program can use it.

Think about the complications arising from doing this to a pointer. A pointer represents a fixed address in RAM. Copying it to a disk file is fine, except that the memory manager has marked it as reusable at this point and a few milliseconds later it could represent something entirely different. Trying to write the pointer now would probably mean a crash.

The fact that memory can be moved and locked this way means that memory is usually allocated as a handle, not a pointer. A pointer points to an address in memory. Windows doesn't want you to think of that memory as your own, so handles, which are pointers to pointers, are often used as a way to make life easier for Windows.

Handles are easier for Windows to swap to disk, but they're alien to the novice Windows programmer. If data abstractions in your programming system are handled correctly, as they are in Turbo Pascal and in some C++ class libraries, the inconvenience of using handles is limited to a very few instances of direct access to the handles, and instead is bound into procedure calls or macros that do the dirty work.

Messages aren't as easily hidden. Some class libraries, like Turbo's brilliant ObjectVision, manage many of them behind the scenes. Others add more messages to the confusion. So will you. Sending yourself a message might come in handy, for example, where pressing a letter key in a spreadsheet-style matrix would begin data entry, whereas most other keys would be ignored. An alphabetic letter message over an empty cell would be preceded by an enter edit mode message, exactly as if you'd double-clicked with the mouse.

Printers and Fonts

One of the nasty rumors spread about Windows is that you don't have to worry about making printer and screen images match up anymore. That's hype. Windows works with jillions of printers; you could conceivably be using a daisywheel printer as your sole hardcopy device. More typically, your printer probably doesn't come with fonts that match the Windows screen fonts.

If the printer does graphics, you can come close to matching, but your program is entirely responsible for getting font widths to match. Usually, thank heavens, all other graphic elements move transparently from screen to hardcopy. But you become responsible for chores that God intended the operating system to handle, not you. Windows gives you no assurance that the Helvetica condensed text appearing onscreen will appear condensed or even as Helvetica on the target printer.

If you've created a draw program and the text is situated snugly inside a rectangle onscreen, there is no assurance--unless your program digs deep into the font metrics of both screen and printer--that it'll still be inside when printed. Now, perhaps, you you see the reason Apple and Adobe want TrueType to succeed. This isn't just feature creep. Just as much as the tens of thousands of journeyman programmers who flood these companies with plaintive tech support questions regarding mismatched screen and printer fonts, the coders who create the operating environment want to get out of the device driver business.

Windows 1 came with an abundant set of painstakingly crafted printer drivers. It was great! The output from my humble ProPrinter looked as good as that from the Mac's Imagewriter. Microsoft didn't enjoy writing all those device drivers, though, and decreed with version 2 that they were the responsibility of the hardware manufacturers. (Understandably so. Device drivers for Windows are difficult enough that most programmers take the easy way out and make a pact with the devil to shorten development time.) Sure enough, I couldn't even do Helvetica on my ProPrinter when Windows 2 came out. And sure enough, Windows 2 went nowhere. Version 3 brought Microsoft back to its roots. Helvetica has finally returned.

Be True to Your Type

By providing an extensive set of font files with Windows and System 7 that will allow screen and printer fonts to be generated from the same raw material, these problems will be histoy. NeXT has been doing it for years now with Display PostScript. Anyone who's used a PostScript printer knows that its speed could be described as glacial on a good day, so how could it come even close to acceptable performance onscreen? Simple. Knowing that the screen (output) resolution is fixed allows the interpreter to omit tons of clipping, error-recovery, and bounds-checking code.

The Windows version, TrueType, is said by those in the know to be hauntingly similar to Display PostScript, and it will be licensed to developers for a pittance. What this means to you is that you'll be able to deal with text as cleanly as you now can with graphics and that Windows will begin to fulfill its long-overdue promise as a programming system that will actually save you time when writing for a variety of output devices.