| Re: [AD] alternate entry point for allegro programs |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> Is the END_OF_MAIN stuff and changing the user's main() function to
> _mangled_main() really necessary?
Short answer, yes - unfortunately.
> 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 know, Allegro's magic main in Windows is just to turn main into
WinMain. This is needed to make programs cross-platform, as Windows
requires the non-portable WinMain function instead of the standard main
function.
In UNIX, all Allegro's main does is grab a copy of argv[0] to get the path
to the executable.
I think, but am not sure, that END_OF_MAIN() doesn't actually do anything
on other platforms.
> 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,
It is something a library that tries to allow code to be recompiled on a
different platform without changing it should bother with. I don't use
Windows, but I like being able to recompile my code without having to
insert an obscure WinMain function.
> 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.
Sounds like you want to disable Allegro's main mangling then. Just #define
ALLEGRO_NO_MAGIC_MAIN before you #include <allegro.h>.
Evert