Windows API – Rob Fahrni

Windows Central: “The next major Windows update, known widely as Sun Valley, is expected to debut in October 2021. Microsoft is planning to unveil the next generation of Windows, and the teaser appears to suggest that a “Windows 11” could be announced.“

I recently replied to a Jennifer Gentleman tweet asking if we’d stuck to a single OS more or less over the years. I was a Windows developer for years and years. From 1989 to 2006 I worked in Windows.

In 2006 I became a development lead for a small team and spent less time writing code. At that time work purchased me a MacBook Pro. I’d SSH to my Linux box and ran Windows in a VM. Even when I went back to being a contributor the same workflow was just fine. It even lead me to building a GDI based renderer for our media pipeline because DirectX wouldn’t work in a VM at that time.

I’ve been all in on Mac since 2006.

At some point Microsoft really shifted focus to web based messaging and I feel like they lost their messaging on the desktop. Now, to be fair, that could have been me falling out of touch with Microsoft and Windows as a developer. It seems like C#/.Net are the definitive language and runtime choice but what about the desktop framework? I’m old. I learned on Win32, AKA the Windows API. It was so simple and straight forward to develop with. Sure it was all C code. Sure it was procedural. None of that mattered. It provided base level functionality necessary to build a great Windows application. Heck, it was really easy to wrap in C++ to build your own framework. My 20 year old little framework still works to this very day.

So, what should you use today to do a great Windows Desktop application? Is it Win32, WinForms, WPF, UWP, or the latest offering, Windows UI 3? Oh, and don’t forget WinRT as a replacement for Win32.

My sincerest hope is Windows 11 is a rework of the Windows user interface that makes everything consistent and that it provides a clear and concise guide for all Windows apps moving forward. So, I’m thinking a combination of WinRT and Windows UI 3 are the way to go.

Here’s hoping Windows 11, or whatever it’s called, gives new life to Windows.

I’d love to build a Windows version of Stream after I complete the Mac version. To that end I’m building a C++ framework just for Stream that handles the network, feed processing, models, and database persistence. That framework will be coupled with a native Windows UI 3 user interface. At some point I believe I’ll bring all that code back to iOS and Mac.

We’ll see.

I was inspired by a recent post by Brent Simmons to write about some ancient C++ code I wrote back in the min-90’s. At that time I was just learning to develop Windows applications in C and C++ was just starting to get some traction, not unlike Swift in the Mac and iOS community today.

When you created a Windows application you’d have to write a WindowProc (Windows Procedure) that would process all messages for a particular window. A Window Proc would receive a message and other parameters. You’d switch on the message and the WPARAM and LPARAM parameters would contain other information specific to a particular message. It was well documented, but it was quite ugly.

Believe it or not this is how a lot of your favorite Windows applications were originally written. Giant switch statements that dissected two other values to determine how to respond to different types of messages.

When I started learning C++ I was trying to find a way to create a Window Proc that didn’t have to implement every Windows message in the system, there must be thousands of them. Could you imagine a base C++ class that responded to every Windows API message in the system? I can’t. It would be a real mess to deal with.

It took me quite a while to come up with a way to do it. I happened upon the answer in the C++ FAQ. This would allow me to create a base class that provided one Window Proc that would look in a dispatch table (a map) to see if the Windows Message was handled by the Window in question.

Here’s what it looked like. I hope this gets the point across.

When you implemented a Window Proc class you would derive from a base class and provide it with a message dispatch table (at the top of the above gist.) The dispatch table would direct the base classes Window Proc to call the correct handler for a specific message.

Notice that this Window Proc is a straight C function. That’s how the Windows API operates. It’s a C based API, but it provides a mechanism to attach user provided data to a Window Procedure. That’s how this operates. When the Windows WM_CREATE message is sent it includes a this pointer to derived Window Class, which can be looked up later based on the HWND identifier.

In the gist above the code that calls pWindow->DispatchMessage knows how to look at the dispatch table and direct the message to the appropriate pointer to a method.

The code that knows how to send a message to a particular method is (this->*pHandler)(wParam, lParam). This is dereferencing a pointer to a method. All methods have the same signature, which is consistent with how the Windows API works.

By the way. This code still builds and runs with up to date versions of Visual Studio on Windows 10. A lot of this code was written in 1995 and has been tweaked over time to keep it up to date with changes to the Windows API.

As I’ve said before, old code never dies.

If you’re feeling really brave you’re welcome to grab my crusty old C++ library and build the simple sample application on your Windows box. Please note, the code is provided as is without warranty, expressed or implied.