The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

What exactly does SDL do with main, and why is this in the library
in this form?

I'm at a loss to understand why we don't just have
two functions

SDL_start
SDL_finish

which encapsulate the prolog and epilog code.
[the old method can be provided in a separate header]

My application code lives in a DLL which is loaded
under program control. You can't fiddle it by macro'ing main.
What am I losing?

--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sorry, I'm trying to sort out exactly what you are asking.

Are you trying to sort out the relationship of SDL2.dll and SDL2_main.dll ?


If you are trying to load up SDL functionality from a DLL, it would be wise for your main program to handle SDL_init and SDL_quit, and the DLL just makes the assumption that this has been done.  If that can't be done, most applications that I've used that use DLL files as plugins typically search for a startup() and shutdown() functions (with varying naming conventions), in which case, you could call SDL_init() and SDL_quit() inside those functions in your DLL file.


Sorry if I'm way off, I'm trying to understand the context of your question, and having a bit of trouble with that.

On Mon, Jun 10, 2013 at 9:37 AM, john skaller wrote:

SDL_main exists because some OSes require a special main() entry point for graphical programs (e.g. WinMain()).  SDL_main makes it so that you can write a single entry point that is cross-platform.  It has nothing to do with initialization of SDL.

Jonny D



On Mon, Jun 10, 2013 at 9:45 AM, Alex Barry wrote:

Also you can by-pass SDL_main on those situations where you don't need
main() at all (e.g. in a library) or you can guarantee the standard
main() will do (e.g. *nix or MinGW). Note how this is relevant only at
*link* time, and only if you include the SDL_main library.

2013/6/10, Jonathan Dearborn:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 10/06/2013, at 11:45 PM, Alex Barry wrote:


I'm asking: what happens here:

#include "SDL.h"
#undef main
int main() // you are NOT stealing my main!
{
...
}



--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 10/06/2013, at 11:56 PM, Jonathan Dearborn wrote:


Are you sure? I ask because I recall with SDL 1.2 it did more,
On OSX it calls some NSxxxxx function to do with memory allocation.

I would be very happy if you're right and I can just ignore it.

[I do think this should NOT be in SDL.h. Interfering with user functions
like that is evil. The convenience can easily be obtained with a separate
header file that is not part of the library. However I can live with it if it
is just a syntactic convenience.]


--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Nope, not sure.  There could be cases where it needs to do more, but in general that is the purpose.  I don't know what OSX requires.

Jonny D



On Mon, Jun 10, 2013 at 10:43 AM, john skaller wrote:

Even in SDL2 it does more, because of the fact that it needs to
recreate the same arguments main() would take (for example, under
Windows it needs to split the command line arguments to make the table
used for argv).

The problem is that one of the main points for using SDL is that it's
portable, and having the prototype of the entry point change for every
platform kind of messes up with that. SDL_main is supposed to help
with that, although you aren't technically required to use it (I
don't, for example, because I can get away without it on the platforms
I work).

And if you think that's bad, consider that on Android it outright
needs a chunk of Java code just to boot, not just a SDL_main function


2013/6/10, john skaller:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 10/06/13 17:36, john skaller wrote:

I've been doing the same for ages now because it clashes with Qt, which
also tries to do the same thing. Both are doing it wrong. #defining
main to anything is just such a bad idea. It also clashed with other
identifiers in my code (I had a main() member function).

If SDL (or Qt for that matter) wants this kind of portability, then tell
the user to write an sdlmain() instead of main(). Then, SDL would
"#define sdlmain main" on most platforms, but to something else on Windows.

#defining main is just asking for conflicts.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/6/10, Nikos Chantziaras:

That won't fix the issue, you'll still end up with multiple entry
points (each library will try to provide its own) and the linker will
complain about that, and in fact it's probably going to be even harder
to fix because you can't do #undef.

Allegro (at least old versions, didn't keep up with Allegro 5) also
overrode main. The catch is that this was entirely done in the
preprocessor rather than with a separate function (the END_OF_MAIN
macro literally was used to define the real entry point). If you
didn't want Allegro doing this all you needed to do is to set the
appropriate #define before including the Allegro header.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 10/06/13 18:12, Sik the hedgehog wrote:

There would be just one entry point: the one you actually implement.
You wouldn't implement both sdlmain() and qtmain().

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

But both would be looking for their respective functions. May as well
just not implement anything and let the user cope with the entry
point.

The real issue is coping with platforms that don't follow the standard
main() entry point, I pretty much refuse to work on anything that
can't work with it. Extremely annoying because the language standard
itself defines it, so the fact every platform has its own way to do it
pretty much defeats the whole point. Honestly I always looked at it
like a way to do lock-in.

2013/6/10, Nikos Chantziaras:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 11/06/2013, at 1:51 AM, Sik the hedgehog wrote:


The C language standard contains a lot of stuff
that is vaguely Unix centric and appropriate for the equipment
that was around at the time. Worse than main(), stdin, stdout.
These make sense on terminals to PDP-11 based unix
systems and not much else.

However the C standard does define "hosted" and
"non-hosted" systems and some stuff is only required
on "hosted" systems.

Actually, this is a good terminology. "Hosted SDL" defines
a standard entry point, but "non-hosted" SDL doesn't.
The non-hosted pure library may need extra support
to work: the question is: what?

My stuff is "Felix hosted" not "SDL hosted" but I still want
SDL to work


--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 10/06/13 18:51, Sik the hedgehog wrote:

They wouldn't have their respective functions. There would only be
main() (or whatever the equivalent is on the system.)

If SDL for example would do:

#define sdlmain main

It means that when you implement an sdlmain() function, in reality
you're defining main(). So it wouldn't matter whether you implement
sdlmain() or qtmain(). Both would result in a main() definition. If
you instead went an implemented both sdlmain() and qtmain(), then you'd
get a linker error because what you're actually doing is implement
main() twice. Which is nice, because you do want that error.



Note that the language doesn't require that you implement main()
yourself. It just says that it has to exist. In Microsoft's case, they
already provide a main() implementation for you, so it exists already.
This doesn't break the standard.




_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If you don't want SDL to redefine your main function, just define SDL_MAIN_HANDLED before you include SDL.h, and then call SDL_SetMainReady() before you call SDL_Init().
The reason it's there is, as people mentioned, there are some platforms that don't use main() as the program entry point, or there needs to be some custom runtime setup that happens before your program runs.


The best way to figure out what this is, is to look in SDL_main.h and see what platforms this is needed on:
#if defined(__WIN32__) || defined(__IPHONEOS__) || defined(__ANDROID__)



On Windows, this is simply a convenience so you don't have to provide WinMain().  If you have that, or you are using a library that needs it, you don't need SDL to provide it.



On iOS, you need to set up an application delegate and start the event system, otherwise your code will crash in really non-intuitive ways during window creation.


On Android, the entry point is Java (unless you're completely using the NDK) and your "main" function is called on a separate thread.


For the mobile platforms some people have proposed a callback based application framework that better matches how the platform works rather than trying to shoehorn it into the "single main function" application model.  I'm certainly open to this, but would want to do this for SDL 2.1.


SDL is zlib licensed and you're welcome to tweak it however you want for your needs.  If you've done something useful for other people, I would ask that you share it with the community.


Cheers!



On Mon, Jun 10, 2013 at 9:26 AM, john skaller wrote:

2013/6/10, Nikos Chantziaras:

If you get to that point then why even bother even with that #define
when the user could just use main() directly and be done with it?
That's what I mean.


When you use WinMain() the main() function doesn't exist. Important
difference. (also even moreso true on MinGW, which can use either
function as the entry point in GUI programs) And again, you still have
platforms like Android where the entry point isn't even in C.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 10/06/13 19:41, Sam Lantinga wrote:

That's SDL2 though. Won't help with SDL1 :-)

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 11/06/2013, at 2:41 AM, Sam Lantinga wrote:


This is good doco! Should go in the Wiki



--
john skaller

http://felix-lang.org



_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

(Oops, hit the "send" button too soon...)

On 10/06/13 19:41, Sam Lantinga wrote:

That won't work either, because I'm never bundling SDL itself in my
software on Linux. I play nice and let it use /usr/lib/libSDL-1.2.so.0.
Can't really modify that one.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I think he does have a point and it's just being dodged here. Having
SDLmain() (or some such) as an entry point for *all platforms* would
be much cleaner than re-using the C "main" function name. I've seen
new SDL users hitting very odd error messages due to the #define
trickery - and all they've tried to make are "plain vanilla" SDL
applications. Once they get a "hello world" running, everything's
fine.

Do note that this is pretty much the last possible moment to change
the entry point - before the release of SDL2.

All that said, I think it would only help people in very specific
circumstances, and there can always be workarounds, and I'm okay
whichever way this goes..

I'll rephrase one more time to try to get my point through.

SDL hides winmain and main and various other entry points. This would
not change. The SDL application entry point's name would change, to
SDLmain, or some other similar name. This would remove the need for
#define trickery, conflicts with other libraries' #define trickeries,
and would still keep SDL applications just as portable as before.

Of course, it would break old code, but only so much that main needs
to be renamed to SDLmain.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/6/10, Jari Komppa:

Not really, because of this:


The ABI is already frozen. Any such changes would break programs built
the moment the ABI was frozen (as they'd expect the current way to do
things) :/

Related question: is there a way to get Visual Studio to use main() on
a GUI program? I know that works on MinGW, but if I recall it
correctly the issue is that Visual Studio still stubbornly requires
WinMain if you don't want a console to pop up. If it can be made to
use main() without popping up the console then that means one platform
less to care about in this sense...
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

As has been said, he's basically running into problems with the macros
(e.g. functions named main inside C++ objects get hit just the same as
the normal main function), so he wants an interface that doesn't
require such macro gimmickry. Requiring SDLmain should do the trick.

The bigger issue would be where to put SDL's startup code to improve
compatibility with e.g. Qt. For that, I think four new functions would
be required: SDL_Preinit to e.g. setup an application delegate,
SDL_Postquit to tear down the same, SDL_Run to do whatever extra stuff
is required to invoke SDLmain (probably nothing, but you never know),
and in a separate object file (so that it's always generated, but only
gets included by programs that care) the platform's required
entry-point.

Preinit would presumably be platform-specific, and so would the
entry-point, but those are normally handled by SDL's provided code, so
no big deal. People that can't deal with that probably should try
doing something else anyways. As for why you would separate Preinit,
Run, and Postquit into three functions, it's because Run obviously
needs to go in between those two, but Run may also need to be called
via the code in some other library. Thus, you need to be able to write
your own entry-point code that uses the SDL pre/post functions, while
having Run called from something else that your entry-point calls,
thus requiring the three functions to be separate for the sake of
correct sequencing. This would probably also be useful as a first step
towards providing an NSAPI backend for SDL 2. If you need to send some
data from Preinit to Run and/or Postquit, then Preinit can just return
a pointer to an opaque structure.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org