Windows 11

I’m excited for Windows 11. It’s nice to see a visual refresh of the user interface and hopefully some of the new top level improvements lead to a better user experience. I’m just excited for the change and it really has me excited about my plans for a version of Stream that runs on Windows.

As an old Windows user and developer I am disappointed with some aspects of Windows 11. Granted, we haven’t seen a final build yet, but I have my doubts we’ll see everything cleaned up between now and release.

I am really disappointed Microsoft has failed to bring the entire user interface forward. Not everything has been refreshed. There’s a really great piece on NTDEV called “State of the Windows: How many layers of UI inconsistencies are in Windows 10?” go read it. It definitely saved me from having to go track down all the icky UI remnants from various different releases of Windows.

One would think it would be a simple matter of creating windows, buttons, and other elements to maintain consistency. Well, not so fast, hoss. Microsoft’s Windows API is extremely rich and allows you to tweak UI elements to your hearts content. Does that explain why certain apps and parts of the OS look so different? Maybe, I’m not at all certain, but it did make me think about how the Windows API works today and how one might make old apps just work in the new Windows 11 world.

Just update the API, dummy

I’m sure there would be a really great discussion on Raymond Chen’s The Old New Thing discussing what an HWND is but I can’t find one at the moment and I’m being lazy so here’s one from a Microsoft getting started guide called “What is a Window?”

The TL;DR for the impatient is this, it’s an identifier assigned by the Windows API when you create a window. It’s a number. That’s it. A button is a window, a list is a window, a radio button is a window. You get the picture. All visual elements are windows. You compose all these things together to create an app UI. Each on is assigned an HWND.

Remember the Windows SDK, or API, is a procedural C based API. You call functions that operate on things maintained by your app and the OS. When you want to take action on a window in your app you do it by using the HWND you’re given as a result of calling CreateWindow or CreateWindowEx.

So, when you’re ready to, say, close your window and be done with it, you’d call DestroyWindow like this:

BOOL destroyed = ::DestroyWindow(hWnd);

That’s it! Your window is now kaput!

So

With that in mind I asked myself “Self, why doesn’t Microsoft update window functions to use Win UI 3 under the hood?” It seems doable, right? Since an HWND is just an identifier why not replace the guts and everything that doesn’t do custom drawing should just work, right?

Well, maybe, I suppose? Throwing out apps that do their own custom drawing might just work but then again there are thousands and thousands of apps out there running on Windows computers. How could you possibly know if all those apps will draw their UI’s properly if Microsoft replaced the guts of all the windows functions? I suppose we can’t?

Having said that, I sure wish there was an easy way for Microsoft to change the base API’s used by so many Windows apps to just work. I have some ideas on the matter beyond just replacing the underlying API’s but no matter how it’s done it would be a ton of work and maybe, just maybe, Microsoft doesn’t want to do that work. Maybe they just want to move forward.

Maybe it’s time to stop worrying about backward compatibility and leave those old nasty Windows API based apps to evolve or rot until nobody uses them any longer?

Maybe.