January 92 - Postcard from Windows Land - Is Windows object-oriented?
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.