SDL_main |
john skaller
Guest
|
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 |
|||||||||||
|
SDL_main |
MrOzBarry
|
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 |
Jonny D
|
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:
|
|||||||||||||||
|
SDL_main |
Sik
|
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 |
|||||||||||||||||
|
SDL_main |
john skaller
Guest
|
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 |
|||||||||||||
|
SDL_main |
john skaller
Guest
|
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 |
|||||||||||||
|
SDL_main |
Jonny D
|
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:
|
|||||||||||||||
|
SDL_main |
Sik
|
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 |
|||||||||||||||
|
SDL_main |
Nikos Chantziaras
Guest
|
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 |
|||||||||||||||
|
SDL_main |
Sik
|
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 |
|||||||||||||
|
SDL_main |
Nikos Chantziaras
Guest
|
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 |
|||||||||||||||
|
SDL_main |
Sik
|
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 |
|||||||||||||||||
|
SDL_main |
john skaller
Guest
|
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 |
|||||||||||||
|
SDL_main |
Nikos Chantziaras
Guest
|
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 |
|||||||||||||||||||||||
|
SDL_main |
Sam Lantinga
|
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:
|
|||||||||||||||
|
SDL_main |
Sik
|
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 |
|||||||||||||||
|
SDL_main |
Nikos Chantziaras
Guest
|
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 |
|||||||||||||
|
SDL_main |
john skaller
Guest
|
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 |
|||||||||||||
|
SDL_main |
Nikos Chantziaras
Guest
|
(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 |
|||||||||||||
|
SDL_main |
Jari Komppa
Guest
|
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 |
|||||||||||
|
SDL_main |
Sik
|
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 |
|||||||||||||||
|
SDL_main |
Jared Maddox
Guest
|
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 |
|||||||||||||
|