Re: [AD] Magic main in Windows

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On August 2, 2004 01:28 am, Elias Pschernig wrote:
> 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?
[snip]
>
> 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
>

I just got a really evil idea.

allegro_init(...)
{
	if(fork() == 0) {
		setup stuff;
		return;
	}
	// else, do stuff, and not return
}

main()
{
	allegro_init(...);
}

Now, getting info to and from the two procs is left as an excercise for the 
reader ;)

j/k. If popen works, that could be usefull, also SHM/mapped files may be an 
option.

Now, communication isn't the only problem I see ;) Synching between the two, 
and actually making the child wait and return some usefull info before 
returning from allegro_init ;)

So yeah. evil. :)

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx
http://strangesoft.net