c++.windows.32-bits - main() & WinMain() together in a Win32 app
- jeanpierre.dumas freesbee.fr (35/35) Nov 07 2002 Platform : Win98SE, compiler Symantec 7.5
Platform : Win98SE, compiler Symantec 7.5 and DigitalMars 8.30 I have a program compiled and linked to make a Win32 GUI application. It is made of 3 parts. 1. a DLL compiled and linked with: CFLAGS=-J -Ju -mn -o+time -WD -ff -ND -5 -a4 -c LFLAGS=/M /NOI /DO /DE /PACKF /WARND /XN /NT LIB=dxguid.lib winmm.lib kernel32.lib gdi32.lib user32.lib In there, among many functions, there is a dllMain(). (The linker complain about it !!!, just a warning, but DllMain() should be part of a DLL, no ?) 2. 2 other C files, one of them containing a "main()" AND the other one a "int WINAPI WinMain()", compiled with: CFLAGS=-o+time -J -Ju -mn -WA -ff -ND -5 -a4 and finally linked with: LFLAGS=/NOI /NODEBUG /NOMAP /NOLOGO /DELEXEC /XNOI /NT LIBZ=..\sc_sdl\sdl_sc.lib opengl32.lib kernel32.lib gdi32.lib user32.lib c.exe: $(CC) $(CFLG) -c $* $(LNK) $(LFLAGS) SDL_main.obj $*.obj, $*.exe,,$(LIBZ) ---------------------------------- Question: It really looks like the linker is getting confused by the simultaneous presence of main() and WinMain(). The programs starts with showing a console, then a borderless window appears, and in the good cases the execution begins. I cannot change the fact that there will be a main() and a WinMain(). WinMain() calls main(). How to tell the linker that no matter what it founds in the code it should consider it as a Windowed Win32 application and enter the code in WinMain() ? I looked at the doc, but could not find any solution out of it. Other question: how to tell the linker not to produce a .map ? I tried almost everything I could read in the doc, but no matter what I find a .map... ? Best regards, Jean-Pierre Dumas
Nov 07 2002
You can't have both a main() and a WinMain(). One will have to change. To not have a .map file, do not link with /M on the linker command. <jeanpierre.dumas freesbee.fr> wrote in message news:aqfq3j$c4h$1 digitaldaemon.com...Platform : Win98SE, compiler Symantec 7.5 and DigitalMars 8.30 I have a program compiled and linked to make a Win32 GUI application. It is made of 3 parts. 1. a DLL compiled and linked with: CFLAGS=-J -Ju -mn -o+time -WD -ff -ND -5 -a4 -c LFLAGS=/M /NOI /DO /DE /PACKF /WARND /XN /NT LIB=dxguid.lib winmm.lib kernel32.lib gdi32.lib user32.lib In there, among many functions, there is a dllMain(). (The linker complain about it !!!, just a warning, but DllMain() should be part of a DLL, no ?) 2. 2 other C files, one of them containing a "main()" AND the other one a "int WINAPI WinMain()", compiled with: CFLAGS=-o+time -J -Ju -mn -WA -ff -ND -5 -a4 and finally linked with: LFLAGS=/NOI /NODEBUG /NOMAP /NOLOGO /DELEXEC /XNOI /NT LIBZ=..\sc_sdl\sdl_sc.lib opengl32.lib kernel32.lib gdi32.lib user32.lib c.exe: $(CC) $(CFLG) -c $* $(LNK) $(LFLAGS) SDL_main.obj $*.obj, $*.exe,,$(LIBZ) ---------------------------------- Question: It really looks like the linker is getting confused by the simultaneous presence of main() and WinMain(). The programs starts with showing a console, then a borderless window appears, and in the good cases the execution begins. I cannot change the fact that there will be a main() and a WinMain(). WinMain() calls main(). How to tell the linker that no matter what it founds in the code it should consider it as a Windowed Win32 application and enter the code inWinMain() ?I looked at the doc, but could not find any solution out of it. Other question: how to tell the linker not to produce a .map ? I tried almost everything I could read in the doc, but no matter what I find a .map... ? Best regards, Jean-Pierre Dumas
Nov 08 2002
I had the same situation with WinMain() calling main(), and the linker getting confused, but renaming main() to mainA() fixed it just fine (But I used #ifdefs to only rename it for windows, since the thing also compiles as a 16-bit DOS program (I'm trying to port it to windows, actually)). Walter wrote:You can't have both a main() and a WinMain(). One will have to change.
Feb 27 2005
Oops, that reply was to a several-year-old thread. Didn't realize Thunderbird sorted OLDEST threads on the top instead of the bottom.
Feb 27 2005