Postcard from Windows Land - Is Windows object-oriented?

James Plamondon

When the Microsoft gang started writing Windows back in the mid-eighties, they were all excited about object programming. They, like Apple, toured Xerox PARC and saw what Xerox was doing with bit-mapped displays, windows, mice, and so on. Microsoft, like Apple, thought this stuff was going to be the wave of the future-so they went home and started working on a cool object-oriented operating system.

Then reality hit. Their target platform, the standard IBM PC of their day, was totally unable to handle the strain of a truly object-oriented system. So, like Apple, Microsoft compromised, and wrote a procedural operating system with an object-oriented flavor.

For whatever reason, however, Windows was unsuccessful throughout its development-until around the time Microsoft's OS/2 deal with IBM fell through-whereas the Mac OS was the star at Apple from soon after its inception. So the Windows operating system is only now beginning to flower, as the Mac OS did about four years ago.

What's amazing to me is how fast Windows is moving. Whereas Apple took ages to bring out System 7, Microsoft is bringing out Windows 3.1 just 18 months (roughly) after 3.0 hit the shelves. And Windows 3.1 should really be called Windows 4; it is a really big improvement over Windows 3.0 (which has sold over five million copies in the last year, so it's no slouch, either).

But is Windows object-oriented? Absolutely not-if, by "object-oriented," you mean written in an object programming language. Given Windows' origins and history, it couldn't be. Smalltalk and Simula were the only decent object programming languages available at the product's inception, and neither would give adequate performance on their target system. So Microsoft did the best it could under the restraints it was under at the time. And in at least one way, Microsoft did a better job than Apple.

Windows, true to its name, has a real windowing system; the Mac does not. This should come as no surprise to MacApp programmers; one of the most important benefits MacApp provides to Mac programmers is-you guessed it-a windowing system, in the form of MacApp views. [A Windows "window" is equivalent to a MacApp "view;" a MacApp "window" is equivalent to a Windows "frame window."] It is considerably easier to write an application framework for Windows than for the Mac, because a Windows framework could use the native windowing system. Zillions of lines of code could be saved.

On the Mac, when you create a window, you get a pointer to a data structure. This data structure is completely dumb. There's no way to call its methods or send it messages. In Windows, on the other hand, one can define a window class, and associate with this class a number of attributes and-importantly-a window procedure (WinProc). When you create a window, you must specify the class of the window. The window reference you get back is a unique window identifier, but it's completely "blind." You can't use it as a pointer to get at its data directly. Instead, you have to "send the window a message" to act on it.

"Sending the window a message" works just like "sending a message" to a Mac CDEF, WDEF, or other code resource. You call a procedure with an integer argument that indicates which message you're sending, and a couple of other arguments that can hold additional data. (Before you snort in disdain at the notion of using integral message discriminators, think about MacApp's use of command numbers in TEvtHandler.DoMenuCommand().)

So, Windows does a better job of data abstraction and encapsulation, at least with regard to window data structures. But is this abstraction and encapsulation enough to make it object-oriented?

Well, maybe not-but there's more. Having defined a window class, one can "subclass" the window class. Now, before you get all excited, let me admit that it's not "real" subclassing, using the definition used by object programming languages. But it's not a bad simulation.

Let's say you want to write a variation of the standard Windows "edit" control-to validate its entries as dates, perhaps. You would need to get a copy of the "edit" class' class info (by calling GetClassInfo()), and modify the resulting copy to use your new class name ("edit_date"). Also, you would save off the class info's pointer to the "edit" class' WinProc, and store the "edit_date" class' WinProc pointer in its place (in the copy). Then, you would call RegisterClass() to tell Windows that the window class existed.

Having done this, you can then create a window of class "edit_date" by telling Windows to do so. It will respond by handing you back a unique window identifier. From then on, both Windows and your application will interact with the window by sending it messages. Messages are sent to the window by calling the Windows function SendMessage() with the window ID as the first argument, or by calling other Windows functions that eventually call SendMessage().

SendMessage()'s prototype is roughly as follows:

long SendMessage(HWND hWnd, short wMsg, short wParam, long lParam);

[This prototype has been simplified for ease of understanding by the MacApp audience. The correct prototype is "LONG FAR PASCAL MyWinProc(HWND hWnd, WORD wMsg, WORD wParam, LONG lParam)."]

"hWnd" is the unique window ID. When SendMessage() is called on a given window, the window's WinProc is called. The WinProc's prototype is almost the same as that of SendMessage(); calling SendMessage() can be viewed as a polymorphic call to a window's message procedure.

The WinProc typically contains a huge switch statement (in Pascal, case statement) that forwards the message to the appropriate message handler (much like TApplication.DispatchEvent()). And, since you carefully saved off the standard Windows "edit" window class' WinProc pointer before calling RegisterClass(), you can call it from within your "edit_date" window class' WinProc-much like calling the inherited implementation of a method in an OOP language. It ain't pretty, but it works.

So, maybe Windows is object-oriented, and maybe it's not. Maybe, as a friend of mine said recently, object-orientation is not a binary, yes-or-no quality, but rather a continuum. If so, then Windows is certainly "more object-oriented" than the Mac OS, while being "less object-oriented" than MacApp.

The answer to the question may be irrelevant. It is relevant, though, that your MacApp experience will put you way ahead of the game in Windows programming. MacApp software development tools are on the cutting edge, while those for Windows are still blunt instruments, suitable only for beating code into submission.

But the bottom line remains the same: Windows is selling at an incredible rate, and will be a significant force in the microcomputer industry for years to come. By learning to program in Windows, you will be assuring your financial security for at least the next decade.

As the old saying goes, in the land of the blind, the one-eyed man is King; and with Windows selling at an incredible rate, the Land of the Blind is expanding rapidly. We MacAppers know how to wring the most out of an even vaguely-object-oriented system; you can see the opportunity this presents to us, even with one eye shut.