Nice work, thanks for getting this fixed! Tested and confirmed this fixes the minimal reproduction in #18621 (comment).

wWinMain also works when using zig cc:

#include <windows.h>

int APIENTRY wWinMain(HINSTANCE hInst, HINSTANCE hInstPrev, PWSTR cmdline, int cmdshow) {
    return 0;
}

zig cc -o test-wwinmain-cc.exe test-wwinmain.c -lc -municode -Wl,--subsystem,windows

> dumpbin /headers test-wwinmain-cc.exe
...
            1180 entry point (0000000000401180) WinMainCRTStartup
...
               2 subsystem (Windows GUI)
...

But is there an intended way to provide -municode when using zig build-exe?

zig build-exe -cflags -municode -- test-wwinmain.c -lc --subsystem windows

doesn't seem to work

fixed

Great! One last thing to make this maximally usable is integration with build.zig. I've added that + a standalone test and submitted it as a PR to your branch here: ypsvlq#1

For future reference, after this PR, here's how to build a C file with all possible entry points using zig build-exe (add -target x86_64-windows-gnu if cross compiling):

zig build-exe main.c -lc

zig build-exe wmain.c -lc -municode

zig build-exe winmain.c -lc

zig build-exe wwinmain.c -lc -municode

(can add --subsystem windows to set the subsystem for the WinMain/wWinMain versions but it's not strictly necessary)

See the added standalone test for the build.zig equivalent.

I'm confused why #18621 is marked as a regression when the fix requires adding a new feature (the -municode flag). How did it used to work?

There are two parts to that issue (and this PR):

• The regression is that if WinMain is defined, it isn't detected/recognized when targeting MinGW and the linker fails with undefined symbol: main. In particular, this comment has a reproduction of only the regression
• The -municode part of this PR is to support wmain/wWinMain which I don't think has ever been fully supported before when targeting MinGW (at least I couldn't get wWinMain to work with 0.11.0)

@ypsvlq can better clarify which parts of this PR address one or the other.

One thing I'd be interested in is if it's at all feasible to make MinGW recognize wWinMain/wmain without needing an explicit CLI flag (e.g. this is the case when targeting MSVC--it will use wWinMain without any CLI flags needed and without needing UNICODE defined AFAICT). Currently with this PR, these are functionally equivalent:

> zig build-exe wwinmain.c -target x86_64-windows-msvc -lc
> dumpbin /headers /nologo wwinmain.exe
           A9AB0 entry point (00000000004A9AB0) wWinMainCRTStartup
               2 subsystem (Windows GUI)

(both the entry point and the subsystem are inferred)

> zig build-exe wwinmain.c -target x86_64-windows-gnu -lc -municode --subsystem windows
> dumpbin /headers /nologo wwinmain.exe
            11A0 entry point (00000000004011A0) WinMainCRTStartup
               2 subsystem (Windows GUI)

(without -municode, the linker errors with undefined symbol: WinMain; without --subsystem windows, the subsystem is 3 subsystem (Windows CUI))

How did it used to work?

The version of mingw used in 0.11 includes the WinMain startup code in crtexe.c, in later versions it has been moved to a separate file which wasn't included in Zig. As far as I can tell wWinMain was never supported.

This is great! Thanks @ypsvlq for working on it! And I believe it will also close #9924 , in which unicode entry points support against mingw was reported missing the first time I guess.