Re: [AD] END_OF_MAIN removal patch for msvc

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On November 16, 2008, Evert Glebbeek wrote:
> On 16 Nov 2008, at 18:09, torhu wrote:
> > I've had some trouble building allegro 5 on msvc, but now I've got
> > it working.  So I've attached a patch which makes END_OF_MAIN just
> > an empty macro on msvc.
>
> Cool. Is there a similar way to do it for MinGW?
>
> > 1) This means that apps built with allegro 5 on msvc will by
> > default have a console window.  But this is what happens on other
> > Windows compilers already, at least mingw does this.  So how to
> > disable the console will definitely become a FAQ for msvc users.
> > Adding the required linker option to allegro headers is an option.
> > See below.
> >
> > #ifdef ALLEGRO_USE_CONSOLE
> >   #pragma comment(linker,"/SUBSYSTEM:windows").
> > #endif
> >
> > Not sure I like this, though.  Seems a bit over the top, or what?
>
> Shouldn't that be #ifndef?
> Anyway, I personally generally dislike #pragma's, but in this case
> I'll go practical and say I have no opinion either way. If we want to
> be newbie-friendly it might be a good idea to have it (my suspicion
> is there'll be more newbies using MSVC than MinGW).
>
> > 2) This opens up the possibility to remove ALLEGRO_USE_CONSOLE and
> > ALLEGRO_CONSOLE_OK.  They're only useful on Windows.  Other
> > platforms always define ALLEGRO_CONSOLE_OK, and ignore
> > ALLEGRO_USE_CONSOLE.
>
> ALLEGRO_CONSOLE_OK is defined if printf() can be meaningfully used,
> right? (Obviously subject to whether the program was started from a
> GUI or not). I can't say I've ever cared about or used either, so the
> implication of pulling these isn't very clear to me.
>
> > 3) OS X and QNX uses END_OF_MAIN to get hold of the address of
> > _mangled_main.  A different solution needed?
>
> As far as I understand the situation on OS X (someone correct me if
> I'm wrong), the problem is that on OS X messages can only be received
> from the main thread. So either we need to have the user respond to
> the messages themselves (obviously not desirable for a multi-platform
> library like Allegro), or we hijack the main thread and run the user
> main() from a thread we create ourselves. This is what the magic main
> does on OS X. As far as I know, there have been a few attempts to
> work around this, but there doesn't seem to be a good solution.
>
> >   And is ALLEGRO_WITH_MAGIC_MAIN needed?  It's off by default.
>
> It might be on *NIX, if there's no other way to grab the commandline
> arguments (which are needed to get the executable path). Disclaimer:
> this is the case in 4.2/3, I don't know if this is still true of 4.9
> of the top of my head.

In most cases grabbing argc/argv isn't required since allegro checks with 
getexename, /proc/<pid>/exe, `ps -p <pid>`, and then argv[0]. Someone should 
check to see what is supported and where. But currently, I dont think MOST of 
the unix platforms have proper GL support, and I only have access to a few of 
them (linux, *BSD, and OpenSolaris), and I'm pretty sure only one of them has 
actual GL support. But then, we won't be stuck with hardware only drivers for 
ever...

> Evert
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx