/**
  * Win32 UTF-8 wrapper
  *
  * ----
  *
  * main() entry point.
  * Compile or #include this file as part of your sources
  * if your program runs in the console subsystem.
  */

#include "src/entry.h"
#undef main

int __cdecl wmain(void)
{
	return win32_utf8_entry(win32_utf8_main);
}

// If both main() and wmain() are defined...
//  Visual Studio (or more specifically, LINK.EXE) defaults to main()
//  Pelles C defaults to wmain(), without even printing a "ambiguous entry
//   point" warning
//  MinGW/GCC doesn't care, and expects wmain() if you specify -municode,
//   and main() by default.
// Thus, we keep main() as a convenience fallback for GCC.

#ifndef _MSC_VER

int __cdecl main(void)
{
	return win32_utf8_entry(win32_utf8_main);
}

#endif

/**
  * Win32 UTF-8 wrapper
  *
  * ----
  *
  * main() entry point.
  * Compile or #include this file as part of your sources
  * if your program runs in the console subsystem.
  */

#include "src/entry.h"
#undef main

int __cdecl main(void)
{
	return win32_utf8_entry(win32_utf8_main);
}

--- 
+++ 
@@ -11,7 +11,24 @@
 #include "src/entry.h"
 #undef main
 
+int __cdecl wmain(void)
+{
+	return win32_utf8_entry(win32_utf8_main);
+}
+
+// If both main() and wmain() are defined...
+//  Visual Studio (or more specifically, LINK.EXE) defaults to main()
+//  Pelles C defaults to wmain(), without even printing a "ambiguous entry
+//   point" warning
+//  MinGW/GCC doesn't care, and expects wmain() if you specify -municode,
+//   and main() by default.
+// Thus, we keep main() as a convenience fallback for GCC.
+
+#ifndef _MSC_VER
+
 int __cdecl main(void)
 {
 	return win32_utf8_entry(win32_utf8_main);
 }
+
+#endif
Define wmain() in addition to main().

Saving those precious nanoseconds that the C runtime would otherwise
waste with needlessly converting the command line from UTF-16 to the
ANSI codepage. Y'know, I figured it might raise questions if I omit
this, and maybe you don't want to have that feel of tainting your build
with an unnecessary ANSI function…

But yeah, entry point precedence *was* a question I had when writing
these wrappers, so at least it serves as documentation now. But yeah,
main() ultimately *is* the superior choice, due to both being
cross-platform and requiring less build configuration.

Now, if GCC had a #pragma to control its entry point selection behavior,
it would be awesome and I'd be gushing with praise at this marvelous
piece of compiler technology. This is still pretty nice though.
