Playing around with CMake and improving that led to the realization that the Windows story has one really annoying flaw in it - Swift's lack of explicit entry point. In particular,
main will be synthesized by the compiler rather than written out by the user. This works great in nearly all the cases. The Darwin targets are granted privileged control via the
And then, Windows. Windows has 4 different entry points which the user must select from:
Currently, we do not have a way to access that entry point. Furthermore, the WinMain signatures have a different signature and provide a different access to the command line:
int main(int argc, char **argv); int wmain(int argc, wchar_t **argv); int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, char *lpCmdLine, int nCmdShow); int wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, wchar_t *lpCmdLine, int nCmdShow);
The interesting things here are:
hInstancewhich is the module instance which is useful for loading resources (practically speaking,
GetModuleHandleW(NULL)should provide a
HMODULEwhich can be used in its stead, as long as it is invoked from the primary module's VA - that is, a library cannot call it and get that handle).
hPrevInstanceis a relic of Windows 16-bit code and ignored
lpCmdLineprovides access to the unprocessed command line (practically speaking,
GetCommandLineWcan get access to it) which can be processed by
nShowCmdindicates the initial state of the window to be rendered
So, it is possible to access the information. However, beyond the signature, the actual behaviour of the application is different based on the subsystem used (Console or Win32). The console applications will launch a console window (
conhost.exe which hosts the application) while the Win32 applications are proper GUI applications and have no console host associated with them. This requires that you manually hide the console window which also means that you have windows flashing when starting up. Furthermore, the type of the application is encoded into the final binary (the subsystem is a flag in the PE/COFF header).
I don't see a good way to actually control this currently. One option is to generalise the
@UIApplicationMain attribute somehow to provide the ability to augment with new application main entries. This would allow a similar flow to the AppKit/UIKit application model for bridging into the Windows main loop (message pump).