However, this approach is easily translatable to a language that has decent FFI, and requires nothing else: no resource compiler and linker to make a resource DLL.
Resource files and their binary format are not a good API.
If you have those CreateWindow calls in a decently high level language, you can probably meta-program some resource-like DSL that fits right in the language.
You don't need a "resource DLL"; the compiled .rc file gets linked directly into the binary, and any Win32 C toolchain is capable of doing that, including MinGW.
As API goes, I don't see what's wrong with it (anymore so than Win32 in general). And you do get quite a lot for free, as GP mentioned. Hi-DPI, for example - .rc files use "dialog units" to measure all widgets, which, unlike raw pixel values you pass to CreateWindow, are DPI-independent.
I don't understand this scenario. If you're writing an .rc file, then by definition you are building your own app (or library, although having one that displays dialogs is rather unusual).
Are you talking about localizable text, by chance?
What if the app isn't in a language that links to an .exe, where we can include the .res file compiled from .rc?
The language may have an .exe run-time, but we don't get to link that.
In that case if we want to use a .rc file anyway, it seems we would want to create a resource DLL out of it and dynamically load it.
(I'm aware that one reason for resource DLL's is for localizable strings. That use makes sense even of programs which can statically link the GUI layout resources.)
Ah, I see what you mean now. But the context is a Win32 app that is very deliberately written in C, so my take was from that perspective - i.e. there's no good reason to avoid .rc files and instead handwrite CreateWindow, handle DPI etc in this case.
However, even in the case that you describe, you don't actually have to use a resource DLL. CreateDialogIndirect can be used to create a dialog from an array of DLGITEMTEMPLATE structs, each describing a single control. I'm not entirely sure, but I suspect that compiled dialogs are basically just a dump of that array (but if not you could always just create it manually).
Resource files and their binary format are not a good API.
If you have those CreateWindow calls in a decently high level language, you can probably meta-program some resource-like DSL that fits right in the language.