| Re: [AD] alternate entry point for allegro programs |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Michael Benfield wrote:
I love Allegro but I have a request for a possible change to Allegro's
internal workings.
Is the END_OF_MAIN stuff and changing the user's main() function to
_mangled_main() really necessary? Couldn't all the stuff that
Allegro's main or _WinMain does just be taken care of by a function
that is called by the user, rather than by a function that hijacks the
program's entry point? As far as I can tell the only thing that the
END_OF_MAIN stuff does that couldn't be done by a normal function is
allowing the user to use main() rather than WinMain() on Windows...
and while that's nice, I'm not sure it's something a game library
should bother with, and even if Allegro must do that, it seems like
that functionality could be separated from all the code that happens
in _WinMain or main.
I agree with you, that END_OF_MAIN() should be changed.
My problem is this: I am trying to create an OCaml wrapper for
Allegro. If I compile a native code binary linked to Allegro, the
entry point of the program is going to be with my OCaml code, not with
Allegro. So there's no way to get to Allegro's main() function.
For Windows, this should help:
... for these programs,
the regular WinMain() is required and the magic must be disabled by
defining the preprocessor symbol ALLEGRO_NO_MAGIC_MAIN before including
Allegro headers.
Your OCaml code will presumably provide a main() function. Your wrapper
would supply a WinMain() function that calls main() and that should
work. You can copy _WinMain() for that.
For Unix, you just need to supply a _mangled_main_address global
variable (pointing to anything), then Allegro will link with your
binary. As long as the OS supports weak symbols, the main() inside your
binary will be used in preference to the main() in the Allegro shared
library. See src/unix/umain.c (you might want to set __crt0_argc/v).
Peter