Re: [AD] Magic main in Windows

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2004-08-02 at 03:46 +0200, Angelo Mottola wrote:
> > Hmm... I was under the impression that MacOS X didn't need the
> > END_OF_MAIN()... looks like I was mistaken. Angelo, any possibility of
> > eliminating it?
> 
> Not really... :(
> 
> The real main() under OSX is actually even executed in a secondary 
> thread... The main thread is special as you can fetch system events 
> from inside it only.
> So the END_OF_MAIN macro under OSX creates a Cocoa application and 
> executes the user main in a newly spawned thread, then keeps on 
> analizying system events until program ends.
> Originally I made Allegro to have the main() symbol defined inside the 
> lib itself; later I adopted the SDL way and used a separated static 
> lib: liballeg-main.a. The code of this module is held in 
> src/macosx/main.m, for anyone interested (you could see why I think 
> it's not possible to remove the END_OF_MAIN from the OSX port)
> 

The only possibilities I could see would be:

Require the user to have two main functions. Something like:

my_main()
{
    /* User program goes here. */
}

main()
{
    allegro_init (my_main);
}

Which looks really bad, much worse than END_OF_MAIN :P

Or require an al_process_events function, which must be called from the
main thread:

main()
{
    while(1)
    {
        al_process_events();
    }
}

But I think we talked about that when you wrotet he OSX port, and it is
against how Allegro currently works.

So, it looks we are stuck with END_OF_MAIN :(

Btw, does that function ordering change in gcc someone recently
mentioned also affect END_OF_MAIN()? If so, we really have a problem..
Maybe we can remove END_OF_MAIN() by some other #define magic.. defining
"main" to something else in allegro.h, then calling that (from another
thread e.g. in the case of OSX).

-- 
Elias Pschernig