Programming Windows: Object-Oriented Programming

Developers creating Windows API-based applications in the C programming language faced many uphill battles, from the complexity of the unsophisticated flat API itself to the nuances of the event- and message-driven paradigms required by the underlying platform. But the bigger issue, perhaps, was related to scale: Even the simplest Windows API applications required a lot of code---which I think of as “scaffolding”---to perform the simplest of tasks: Define a window. Create a window based on that definition. Start a message loop, looking for events to which to respond. And so on.

Developers typically look to some type of code reuse to make repetitive tasks easier over time. And in those days, code reuse took two forms: Copy and paste, where the C scaffolding for one application was literally copied into the code for a new application so that it could be changed as needed, and function library creation, where a developer could create his own libraries of boilerplate code to hide the scaffolding in sub-files and keep the main program file cleaner and easier to read. Indeed, many early Windows developers would even go far as to strip Microsoft’s massive C header files of functionality not required by their apps to save space, improve performance, and make the resulting collection of source code more manageable.

C is a product of its era, but by the time Microsoft adopted it for Windows, it was already being superseded by an object-oriented extension originally named “C with Classes,” and then C++. This new take on the language adopted the objected-oriented principles discussed below and allowed developers to embrace a more modern development paradigm. But it would be several years before Windows application developers could take advantage of the language improvements in C++, let alone any C++-based libraries that would further reduce the drudgery.

Consider, again, Petzold. In the very first edition of Programming Windows, which was published in 1998, Mr. Petzold referred to “objects” again and again.

“In object-oriented programming,” he wrote, “an ‘object’ is an abstract data type that consists of a data structure and various functions that act on that data structure. Objects receive ‘messages’ that cause them to change (that is, perform operations on) themselves.”

This language should sound familiar. Even in a non-OOP language like C, it is possible to create an object like a window, that consists of a data structure---the window class---and receives messages to which it can respond. You can see the difficulty of doing such a thing in straight C and the Windows API in Programming Windows: Hello, Windows (Premium).

Now, this doesn’t mean that C-based Windows programming was object-oriented. It’s more “object-based,” to reuse a phrase I used to describe Visual Basic, though these two environments couldn’t have been less alike from a practical day-to-day sense. But the rationale was there:...