search

wilzbach / tools-test

1 stars 0 forks source link

wWinMain and wmain fail to link #91

Open wilzbach opened 11 years ago

wilzbach commented 11 years ago

Note: the issue was created automatically migrated from https://issues.dlang.org

Original bug ID: BZ#10034 From: Diggory <diggsey@googlemail.com> Reported version: D2 CC: andrej.mitrovich@gmail.com, simen.kjaras@gmail.com

wilzbach commented 11 years ago

Comment author: Diggory <diggsey@googlemail.com>

Fairly self explanatory, unicode versions of WinMain and main cause a bunch of undefined symbol errors such as:

Error 42: Symbol Undefined _D15TypeInfo_Struct6__vtblZ

Followed by the message:

OPTLINK : Warning 134: No Start Address

wilzbach commented 11 years ago

Comment author: Andrej Mitrovic <andrej.mitrovich@gmail.com>

Unicode version, what do you mean? AFAIK there's only one possible win main function called WinMain.

wilzbach commented 11 years ago

Comment author: Diggory <diggsey@googlemail.com>

Windows also supports "wmain" and "wWinMain" which are wide character versions of "main" and "WinMain".

wilzbach commented 11 years ago

Comment author: Simen Kjaeraas <simen.kjaras@gmail.com>

Windows supports neither WinMain nor wWinMain. Windows supports a starting address. MSVC, on the other hand, supports both WinMain and wWinMain. According to documentation, WinMain is the official entry point, and wWinMain is magical, in that it creates a thunk that calls GetCommandLineW and passes that to wWinMain.

DMD would thus be free to call its Unicode version of WinMain wWinMain, WinSecondary, foo, or anything else (same goes for the ANSI version). It could even (gasp!) call it WinMain, and create a thunk if the parameters indicate it should be using Unicode.

See remarks here: http://msdn.microsoft.com/en-us/library/ms633559.aspx