delete std.os.windows.user32

[andrewrk]

Please use a third party package such as the excellent zigwin32gen project if you want to use the Windows API directly.

This is progress towards #4426
Closes #17417

[d3c0d3d]

Bad decision, removing something small and functional in favor of something large and bloated that not everyone was able to configure directly because there is no adequate documentation.

[expikr]

I'm in favor of removing it from the std.

But it shouldn't be deleted outright, nor should it just be moved to the std graveyard directly.

I'd like to suggest setting up dedicated projects for the individual DLLs,

i.e. ziglang.org/zig.user32 etc

The user32.zig presently being removed has two advantages over zigwin32:

1. It is organized according to how you'd look it up on MSDN, whereas zigwin32's arbitrary namespacing makes it impossible to find what you need
2. The handcrafted wrapping around the functions sets a good example of what idiomatic std interfaces looks like.

[squeek502]

Just want to note:

removing something small and functional in favor of something large and bloated

I'd like to suggest setting up dedicated projects for the individual DLLs,

Creating a third-party library that provides small and functional / hand-crafted win32 bindings is something anyone is free to do, and indeed would be nice to have.

[expikr]

Why not SW_SHOWDEFAULT? (10)

[e4m2]

Certainly a better default than just SW_SHOW and okay for passing it to ShowWindow(), however nCmdShow in WinMain should contain the real value instead. You can get it like this:

const cmd_show = if (peb().ProcessParameters.WindowFlags & STARTF_USESHOWWINDOW != 0) peb().ProcessParameters.ShowWindowFlags else SW_SHOWDEFAULT;

Also I would be in favor of defining whatever constants are needed locally/leaving a comment, since just saying "5" or "10" isn't very useful.

---

Unrelated, but I think all the kernel32 usage in that file could be replaced by:

// GetModuleHandleW(null)
peb().ImageBaseAddress

// GetCommandLineW()
peb().ProcessParameters.CommandLine

// ExitProcess(status)
RtlExitUserProcess(status)

[squeek502]

Nice! All of these changes would make a great PR if you're up for it.

(I was also looking into this and found the PEB solution but missed the STARTF_USESHOWWINDOW wrinkle 👍)

[d3c0d3d]

@expikr When I saw for the first time that Zig had the Windows API (or the minimum of it) in its core “std” in a simple and accessible way without depending on third-party packages, I thought it was wonderful, I come from Rust where the core is tiny There is no practically nothing and it is necessary to install outdated and poorly documented third-party libraries, I thought I was in paradise, now that they are removing it from Zig, for me it is a bad sign, for me something like "if you want to use this thing, turn around and good luck", that's the impression I have.

[expikr]

I think the bigger problem is that calling extern functions doesn't seem to be mentioned by any tutorials anywhere, but it's actually quite simple to do without requiring any complicated abstraction at all (which bloated libraries would mislead you into thinking it to be the case).

https://github.com/ziglang/www.ziglang.org/blob/master/assets/zig-code/samples/0-windows-msgbox.zig

const win = @import("std").os.windows;

extern "user32" fn MessageBoxA(?win.HWND, [*:0]const u8, [*:0]const u8, win.UINT) callconv(win.WINAPI) i32;

pub fn main() !void {
    _ = MessageBoxA(null, "world!", "Hello", 0);
}

I learned it by reading how they're declared in the user32.zig file, and I wouldn't have discovered it in the first place if it hadn't been in the std.

The presence of it being implemented in a single straightforward file provided an invaluable demonstration, it would be unwise to throw away the ladder after having already climbed it.

[squeek502]

now that they are removing it from Zig, for me it is a bad sign

Note that this decision was made over 2 years ago in #4426. Here's a relevant comment from May 20, 2021 (#8776 (comment)):

Will merge this since it is a fix, but keep in mind that user32.zig will probably be entirely removed at some point.

---

"if you want to use this thing, turn around and good luck"

I see it more like "there's so much of this thing that people might want to use that it's probably better that the people actually using it take control" (note that user32.zig was entirely unused and untested by Zig itself). A third-party project that focused on providing user32 bindings would likely be able to provide well-tested and better overall bindings for the relevant use cases.

And, as @expikr points out, it's pretty easy to write up bindings for whatever Win32 function you need without any library at all (something I did a lot of myself for this).