root source file has no member called 'main' when WinMain is defined.

[JesseRMeyer]

On Zig 0.5.0+a11da3773.

zig build-exe ../src/test.zig --subsystem windows
C:\dev\Zig\lib\zig\std\special\start.zig:227:35: error: root source file has no member called 'main'

usingnamespace @import("std").os.windows;

extern "user32" stdcallcc fn MessageBoxA(hWnd: ?HANDLE, lpText: ?LPCTSTR, lpCaption: ?LPCTSTR, uType: UINT) c_int;

export stdcallcc fn WinMain(hInstance: ?HINSTANCE, hPrevInstance: ?HINSTANCE, lpCmdLine: ?LPWSTR, nShowCmd: INT) INT {
    _ = MessageBoxA(null, c"hello", c"world", 0);

    return 0;
}

Interestingly, the error is only prompted if stdcallcc is not provided, but it's required otherwise the parameters are not accessible to the function as the calling convention is not observed.

If main() is defined then WinMain() is never called.

[JesseRMeyer]

To my knowledge this is a show stopper for Windows development for any instance where WinMain's function parameters are required.

[JesseRMeyer]

This problem continues to persist in build 0.5.0+008e42f48 (12/07/2019).

Minimal repo.

usingnamespace @import("std").os.windows;

export stdcallcc fn WinMain(hInstance: ?HINSTANCE, hPrevInstance: ?HINSTANCE, lpCmdLine: ?LPWSTR, nShowCmd: INT) INT {
    return 0;
}

[Vexu]

WinMain has to be pub.

[JesseRMeyer]

I thought exporting implied the function was public? Where are the rules on that? Easy and confusing situation to get oneself in either case, so I think Zig would warn more helpfully in this situation, which I'm sure is going to continue to happen as Zig grows more alluring to win32 devs.

[andrewrk]

I agree it's a bit counter intuitive at the moment. This area of the language is unstable.

#1717 is accepted. That will probably encourage reconsidering #181, so that something as common as defining a function is not tedious. There is also #661.

export is technically not needed. One could do this (hypothetically with above 3 things implemented):

let foo = fn (hInstance: ?HINSTANCE, hPrevInstance: ?HINSTANCE, lpCmdLine: ?LPWSTR, nShowCmd: INT) callconv(.stdcallcc) INT {
    return 0;
}

comptime {
    @export("WinMain", foo, .Strong);
}

It's also possible for the root source file to import a different file which actually does the export of WinMain. The start code does not have access to find out what is or isn't exported, and it's using @hasDecl as a way for the root source file to communicate in a convenient way that it wants to be in control of this symbol.

So, for now, the thing to do is slap a pub on there while waiting for the language to stabilize. I'm confident that moving the logic out of the compiler and into the start code was a good move; let's let it guide us further along the path toward what the final language / standard library will look like.

[mogud]

@andrewrk Did you considered about adding builtin user defined properties support? Maybe calling convention is a relevant stuff. In addition, some useful properties like deprecated and future used can be introduced.