Dave's Garage on YouTube has a couple good videos that I can recall.

https://www.youtube.com/watch?v=JlZe2JwrJqM

https://www.youtube.com/watch?v=CyJw2MumgTQ

Oh! I gonna dive into this pretty soon. Thank you!

It looks like a pretty clean example from what I can recall.

WinMain builds the window and starts the message pump. The pump is implement starting at line 425. It's basically a while loop that reads the next message on the stack, translates it, then sends it to the object it belongs to.

It's the precursor to today's modern event-driven designs. Basically, this is now done for you by the runtime.

The bulk of the action happens in the created window's "wndproc", cbMainWindow (Line 455 - 2897).

There's a giant switch statement, with each handled message being a separate case. There's also a WM_COMMAND message, which is essentially a message holding another message inside.

This is probably the best book on Win32 API programming out there.

https://www.amazon.com/Programming-Windows%C2%AE-Fifth-Devel...

Yes, it's unfortunate that Programming Windows after 5ed became about XAML and C#. Those are good tools, but it's sad that they stopped updating the Win32/C++ resources as well.

Use ChatGPT! It's night and day for Win32 dev in my experience, and the code it produces is really good.

One thing to note before going into Win32: You're going to have a pixelated, upscaled ui if you don't take care of high dpi support yourself, and that involves patching system controls. So prepare yourself for lots of dpi-work if that's a concern. (One thing I've been experimenting with is superclassing the system controls and "overwriting" the original by registering a superclass of eg. the edit control as simply "edit". This makes other system controls, like the combobox, use your dpi scaled/custom version).

Exactly my experience. In general, for the sane person, it is impossible to write more than a few lines of Win32 API code without copy/paste... ChatGPT came quite handy here.

I'm confused. Are you sure high DPI needs patching system controls to avoid pixelation? Doesn't dpiAwareness avoid the pixelation? I certainly haven't needed to patch anything for this in the past. If you have an example you could point to, that would be great, since I don't know if I'm missing something here.

Also, question: do you know of a good way to test for high-DPI mode on a low-DPI screen?

You just need to add a manifest to your app indicating that you support high DPI. To test your app just change the DPI in the display settings.

I guess I was hoping for something little clunky than that, but thanks for the suggestion.

Nope, you get the pleasure of implementing dpi support yourself.

https://building.enlyze.com/posts/writing-win32-apps-like-it...

Thanks for the link. Glancing at it, I still don't see where there's a need to patch system controls for high DPI support, though. The closest thing I see there is for changing their fonts, but that seems different from patching them (no superclassing that I can see, etc.). Moreover, it's for dynamic DPI support (i.e. supporting DPI changes), not high DPI support. Is that what you were referring to?

I think you should try a plain win32 program on a high dpi and just see for yourself.

That's not exactly a... helpful answer. In fact I already have a Win32 (dialog-based, if that makes any difference) one that looks just fine on 200% DPI on Windows 10. All it required handling was scaling the obvious stuff (icon sizes, overall window size, etc.) and the manifest, nothing that required superclassing or otherwise patching common controls. i.e. I just haven't run into the problem you're mentioning. I'm kind of confused why you linked to an article that doesn't support your claim either. Hence why I'm asking you instead of spending hours trying to reproduce what you're saying.

I don't know why you assume I'm here to give you helpful answers, but I'll bite.

Try a combo box on high dpi. The arrow button gets a lot thinner than on 96 dpi.

Reply to your answer below: That is not the default Win32 combobox. I don't know what you're using, but it's not the plain c api

I didn't assume you'd give a helpful answer, but I didn't expect you to give that kind of an answer, either. You're always welcome not to respond if this is taking too much of your time. I figured maybe at least one of us would learn something about high DPI issues, hence why I engaged.

And I did just try what you said and the combo box fine to me: https://imgur.com/a/Mb83tPj

That is not the default Win32 combobox. I don't know what you're using, but it's not the plain c api.

That is the default combobox if you enable "visual styles" (which you should do on Windows XP and above)

binjooou: The whole point for me when using win32 is to use the default look, since it's a better ui compared to todays flat design. But I acknowledge that there could be a little less dpi work associated with enabling visual styles.

The best UI is the UI your users are used to, and 1% of Windows users are used to the Win 2000 gray UI.

Win XP came out 22 years ago.

oblio: Have you seen the other comments for this post? There's plenty of people who think the default win32 gui is awesome.

This is most definitely the default combo box. At this point I'm very confused what you are using.

dataflow: That is indeed a nice looking combobox in your new screenshot. I'm not getting that result on win10 when using the Win32 c api, and if you're not using something like WinForms, MFC or another abstraction, it's hard to say why it works for you. I'm on a 4k resolution with 200% scaling and the button is way too thin.

I'm not sure if this makes a difference but do you see that problem with dialogs (resources + DialogBox) rather than basic windows?

If I remember & get a chance later I can try to make a minimal example.

No, win10

When you load a dialog from resource, windows scales it proportionally to specified font size (DS_FONT style).

I love that this has been built with the old-school API! I've done a bit over the years and find it kind of pleasurable (maybe I enjoy torture!).

Agreed! Sadly, lean GUI apps are mostly a thing of the past now.

I had the same idea until I opened main.cpp and scrolled through 8911 lines of code

This also brought back memories for me of writing Win32 apps. If you're looking for a good book, checkout Programming Windows by Charles Petzold. It really demystified a lot of things for me and I bet it's still relevant if you want to write stuff like this.