We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 325

Summary: "main" is defined in sdl_main when building a console application
Product: SDL Reporter: Erik Faye-Lund <kusma>
Component: mainAssignee: Ryan C. Gordon <icculus>
Status: RESOLVED WONTFIX QA Contact: Sam Lantinga <slouken>
Severity: trivial    
Priority: P2    
Version: HG 1.2   
Hardware: x86   
OS: Windows (All)   

Description Erik Faye-Lund 2006-09-11 15:36:03 UTC 
if

#define main	SDL_main"

is changed to

#ifdef _MSVC_VER
#pragma comment(linker,"/ENTRY:mainCRTStartup")
#else
#define main	SDL_main
#endif

in sdl_main.h, an unneccesary dependancy on SDLmain.lib could be eliminated.
Comment 1 Sam Lantinga 2006-09-23 20:38:22 UTC 
The whole reason main is defined to SDL_main is to have SDL applictions link with SDLmain.lib on Win32 by default.  You're welcome to redefine it however you want for your application, of course.
Comment 2 Erik Faye-Lund 2006-09-24 13:06:39 UTC 
I don't see why you want anyone to link to SDLmain.lib in the first place. The problem with win32-programs using WinMain instead of main as the entry-point is a build-configuration thing much more than anything else, and that can be fixed with the change i proposed. It seems to me that you haven't really looked at the proposed change and/or realized the problems SDLmain.lib cause.

One example of such an issue is that SDLmain.lib does not work with Visual Studio 2005 (due to linking to the wrong CRT - in the latest pre-built release at least), making hack-free (ie non-macro-hell) cross-platform programs using vs2k5 and sdl very tricky to set up. SDL.lib does not seem to have the issue of depending on the wrong CRT.
Comment 3 Sam Lantinga 2006-09-24 14:15:24 UTC 
The real reason I recommend that people link with it is so that DirectInput works.  The SDL_SetModuleHandle(GetModuleHandle(NULL)) call needs to be made from the main application code, otherwise DirectInput fails to initialize on several versions of Windows.

There's a reason why the binary packages are compiler specific - the C library linking issue is one of them.

You are of course free to change it however you like, which is why SDL_win32_main.c is in the public domain.

SDL 1.3 eliminates the need for SDLmain.lib entirely, simply by not using DirectInput (for the moment)