Allegro game programming library

Evert Glebbeek:
> Tested under Windows 98 with a year-old MinGW (gcc 3.2.3) and Allegro 4.1.12,
> this program compiles without warnings and runs as would be expected, both from
> a terminal and from the file manager, rather to my surprise.

Also works fine under Windows XP with latest MinGW (GCC 3.4.1) and Allegro
4.1.14.

> So why exactly do we need END_OF_MAIN() in Windows?

No idea. SDL also hides WinMain() but doesn't require the use of a macro. I
don't remember how they do it; maybe worth examining.

--
Daniel Schlyder
http://bitblaze.com/

On Sun, 2004-08-01 at 18:30 +0200, Daniel Schlyder wrote:
> Evert Glebbeek:
> > Tested under Windows 98 with a year-old MinGW (gcc 3.2.3) and Allegro 4.1.12,
> > this program compiles without warnings and runs as would be expected, both from
> > a terminal and from the file manager, rather to my surprise.
> 
> Also works fine under Windows XP with latest MinGW (GCC 3.4.1) and Allegro
> 4.1.14.
> 

We should try it with MSVC I guess. It looks like normal main() just
works in Windows. Oh, and I'm cc-ing this to Eric, he is the windows
expert, maybe he remembers a reason why END_OF_MAIN is needed there.

> > So why exactly do we need END_OF_MAIN() in Windows?
> 
> No idea. SDL also hides WinMain() but doesn't require the use of a macro. I
> don't remember how they do it; maybe worth examining.
> 

Yes, definitely could be worth examining. But from the above tests it
looks WinMain simply isn't needed in windows programs at all.

-- 
Elias Pschernig

On Sunday 01 August 2004 18:30, Daniel Schlyder wrote:
> No idea. SDL also hides WinMain() but doesn't require the use of a macro. 
I
> don't remember how they do it; maybe worth examining.

Looks like SDL just pulls a #defines SDL_main main in it's main include 
file and calls that.
Not sure if that means that you can't use your own WinMain though... I 
guess it doesn't but how they worked around that I don't know.

Evert

At 06:06 AM 2/08/2004, you wrote:
>On Sunday 01 August 2004 18:30, Daniel Schlyder wrote:
> > No idea. SDL also hides WinMain() but doesn't require the use of a macro.
>I
> > don't remember how they do it; maybe worth examining.
>
>Looks like SDL just pulls a #defines SDL_main main in it's main include
>file and calls that.
>Not sure if that means that you can't use your own WinMain though... I
>guess it doesn't but how they worked around that I don't know.


the allegro docs say this:

The Windows, Unix and MacOS X versions require you to write END_OF_MAIN() 
after your main() function. This is used to magically turn an ISO C style 
main() into a Windows style WinMain(), or by the Unix code to grab a copy 
of your argv[] parameter, or by the MacOS X code to shell the user main() 
inside a Cocoa application.

personally i use:

int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR 
lpCmdLine, int nCmdShow)

instead of   int main(int argc, char *argv[])

as i need a copy of the hInstance,  maybe allegro needed it at some point.

On Sunday 01 August 2004 22:18, aj wrote:
> the allegro docs say this:

I know what the Allegro docs say ;)
I was refering to SDL; I don't know if and how you can create your own 
WinMain. Not that I'd know how to test that anyway.

> The Windows, Unix and MacOS X versions require you to write END_OF_MAIN() 
> after your main() function. This is used to magically turn an ISO C style 
> main() into a Windows style WinMain(), or by the Unix code to grab a copy 
> of your argv[] parameter, or by the MacOS X code to shell the user main() 
> inside a Cocoa application.

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?

Evert

On Sunday 01 August 2004 22:06, Evert Glebbeek wrote:
> Looks like SDL just pulls a #defines SDL_main main in it's main include 
> file and calls that.

Yes. In Windows, SDL defines
#define SDL_main main
and then calls SDL_main from its own WinMain.
It can get away with this by requiring that main be declared as
int main(int argc, int *argv[])
Any other declaration of main fails.

Not something we want to do for Allegro IMO. 

Evert

Evert Glebbeek:
> Yes. In Windows, SDL defines
> #define SDL_main main
> and then calls SDL_main from its own WinMain.
> It can get away with this by requiring that main be declared as
> int main(int argc, int *argv[])
> Any other declaration of main fails.

You mean "char *argv[]", of course.

> Not something we want to do for Allegro IMO. 

Why not? AFAIK, there's only two legal definitions anyway: that one, and the
one without any arguments. From a user's point of view, I think it would be
less of an inconvenience to have to define main() that way, than use the
END_OF_MAIN macro. Heck, most games probably want to support a few command line
options, anyway.

--
Daniel Schlyder
http://bitblaze.com/

> 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)

--
Angelo Mottola
a.mottola@...
http://www.ecplusplus.com

>
> 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)

It's not clear to me why this necessitates END_OF_MAIN. What is to 
prevent all this functionality from being done by a normal function 
that the user calls? The function could create a Cocoa application, 
start a new thread to analyze system events, and then return back to 
the user.

Nevermind, I'm an idiot, I didn't catch this part.


>> The main thread is special as you can fetch system events from inside 
>> it only
>

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

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@...
http://strangesoft.net

On Monday 02 August 2004 09:28, Elias Pschernig wrote:
> Btw, does that function ordering change in gcc someone recently
> mentioned also affect END_OF_MAIN()?

=46rom what I've seen of how END_OF_MAIN() works, it shouldn't.

> 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).

The problem is the number of possible ways main can be defined. We don't=20
know if we're dealing with main(int, char **)  or main(void).
That could be worked around by using a function pointer and a cast though,=
=20
as Allegro currently does on UNIX (see src/unix/umain.c).

Evert

Was thinking some more, maybe like this, for OSX:

/* In Allegro. */
int main(int argc, char **argv)
{
    /* Possible create thread. */
    dummy_main(argc, argv);
}

/* In allegro.h */
#define main dummy_main

/* User program. */
int main(int argc, char **argv)
{
    allegro_init ();
    while(!key[KEY_ESC])
    {
    }
}

-- 
Elias Pschernig

Elias Pschernig wrote:
> Or require an al_process_events function, which must be called from the
> main thread:

You mean, like the polling functions we have now? ;) Though I know how 
much everyone /looves/ polling. Perhaps allegro_init() could spawn off 
into a new thread, continuing the user code where it left off, and in 
the main thread, do whatever it does now? The only problem I see is that 
the new thread won't know where to return to from allegro_init.

> Btw, does that function ordering change in gcc someone recently
> mentioned also affect END_OF_MAIN()?

AFAIK, END_OF_MAIN takes care of the different main declaration 
possibilities.

> 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).

I still think using al_main would be best. al_main is an actual, 
user-created function. Then, Allegro supplies its own main function that 
calls al_main. So, you'd have this:

#define al_main \
al_main(whatever we decide is best here); \
int main() /* or WinMain */ \
{ \
    allegro_init();
    return al_main(); \
} \
int al_main

The use would just have:

int al_main(...)
{
    // program as normal
}

which would turn into:

int al_main(whatever we decide is best here);
int main() /* or WinMain */
{
    allegro_init();
    return al_main();
}
int al_main(...)
{
    // program as normal
}

Though as I said last time, I don't know how well this would integrate 
with Allegro's current END_OF_MAIN hacks.

I wrote:
> I still think using al_main would be best. al_main is an actual, 
> user-created function. Then, Allegro supplies its own main function that 
> calls al_main. So, you'd have this:
> 
> #define al_main \
> al_main(whatever we decide is best here); \
> int main() /* or WinMain */ \
> { \
>    allegro_init();
>    return al_main(); \
> } \
> int al_main

And an added benefit of this: to disable Allegro taking over 
main/WinMain, all you'd have to do is simply not make an al_main 
function. Though also, using a define like this means we can't let the 
user prototype al_main after the define is defined (not that you'd need 
to anyway, but yeah..).

- Kitty Cat

On Monday 02 August 2004 09:54, Chris wrote:
> You mean, like the polling functions we have now? ;) Though I know how 
> much everyone /looves/ polling. Perhaps allegro_init() could spawn off 
> into a new thread, continuing the user code where it left off, and in 
> the main thread, do whatever it does now?

There is no guarentee that the user will call allegro_init() from the main 
thread. Considering Allegro's current poor multithreading support, this is 
no much of an issue yet, as the user probably has to do that.
If we want to improve the thread safety of Allegro, then I don't think we 
can assume that.

> I still think using al_main would be best. al_main is an actual, 
> user-created function. Then, Allegro supplies its own main function that 
> calls al_main. So, you'd have this:

I tried doing something like that to the Windows port last night, changing 
main to WinMain. Didn't work, but could have been me just being clumsy.
Personally, I don't like requireing the user to write an al_main() rather 
than a main() function.

As I said, SDL handles this by (always) redefining main() on Windows and 
requiring that it be int main(int, char**). We could get around the 
requirement of having main(int, char**) by using a function pointer and a 
cast (as in src/unix/usystem.c).
The only thing that is unclear to me is if and how the user is able to 
disable Allegro's magic main handling in this case. I got the impression 
that in SDL, you simply can't, but I can't imagine that's right...
SDL's WinMain seems to be in a seperate sourcefile that is (statically?) 
linked to the executable. Allegro's current magic WinMame is created in 
the headerfile from the END_OF_MAIN() typedef.

Evert

Evert Glebbeek wrote:

>>I still think using al_main would be best. al_main is an actual, 
>>user-created function. Then, Allegro supplies its own main function that 
>>calls al_main. So, you'd have this:
>>    
>>
>
>I tried doing something like that to the Windows port last night, changing 
>main to WinMain. Didn't work, but could have been me just being clumsy.
>Personally, I don't like requireing the user to write an al_main() rather 
>than a main() function.
>  
>

I think we should just leave the END_OF_MAIN() stuff as-is for Windows.  
It's not that bad, and it can be easily disabled with a preprocessor 
constant.  The worst problem with END_OF_MAIN() was in Unix and that's 
nearly sorted out.

Peter

Evert Glebbeek wrote:
> Personally, I don't like requireing the user to write an al_main() rather 
> than a main() function.

They wouldn't be required to use al_main. As I said in the reply, to 
disable this behavior, all you have to do is not create an al_main 
function. That way, al_main will never be replaced with the define that 
creates main/WinMain (because it doesn't exist).

Basically, the user would code this:

int al_main(...)
{
}

The C-preprocessor will get the 'al_main' define and turn it into this:

int al_main(...);

int main()
{
    allegro_init();
    return al_main();
}

int al_main(...)
{
}

Now, if the user doesn't want auto-main-handling, he'd simply not create 
al_main and the define will never be expanded to make the main/WinMain 
function.

- Kitty Cat

On Monday 02 August 2004 10:42, Chris wrote:
> They wouldn't be required to use al_main. As I said in the reply, to 
> disable this behavior, all you have to do is not create an al_main 
> function. That way, al_main will never be replaced with the define that 
> creates main/WinMain (because it doesn't exist).

I'm not sure that this helps with platform independence, which I think is 
the main reason we need to change main to WinMain on Windows.
(Or turn WinMain into main, depending on your point of view).

I certainly won't be happy if a lot of Allegro programs suddenly start 
using WinMains.

This reminds me, I had some reasonable succes using Allegro (with the GDI 
driver) with winelib to compile a Windows program that had a custom 
WinMain a while back. I'll see if I can dig up what it took me to get that 
working, as it may be worth a footnote in the docs somewhere.

Evert

On Mon, Aug 02, 2004, Evert Glebbeek wrote:

> The problem is the number of possible ways main can be defined. We don't 
> know if we're dealing with main(int, char **)  or main(void).

   Most compilers support variadic macros nowadays, so we could use
something like that:

   #define main(a,b...) \
      _mangled_main(a,##b); \
      int main(int argc, char *argv[]) \
      { \
         int (*real_main) (int, char*[]) = \
            (int (*) (int, char*[])) _mangled_main; \
         __crt0_argc = argc; \
         __crt0_argv = argv; \
         return (*real_main)(argc, argv); \
      }; \
      int _mangled_main(a,##b)

   This does not require END_OF_MAIN, and works whatever the definition
of main. It requires that main() is not prototyped after <allegro.h> has
been #included, though.

-- 
Sam.

Evert Glebbeek wrote:
> I'm not sure that this helps with platform independence

Yeah it does, because the define that expands al_main can create any 
entry point function that does anything it needs. It can create WinMain 
in Windows, and main everywhere else. As well, for OSX it could create a 
main that starts a thread explicitly at al_main, leaving main to do the 
special input thread stuff.

> I certainly won't be happy if a lot of Allegro programs suddenly start 
> using WinMains.

I don't see why they would have to?

- kitty Cat

On Monday 02 August 2004 11:39, Chris wrote:
> Yeah it does, because the define that expands al_main can create any 
> entry point function that does anything it needs. It can create WinMain 
> in Windows, and main everywhere else. As well, for OSX it could create a 
> main that starts a thread explicitly at al_main, leaving main to do the 
> special input thread stuff.

In that case, if we have a #define al_main main on platforms that don't 
require main maming, I'd prefer to just have a main() as we do now and 
modify that.

Evert

Sam Hocevar wrote:
>    Most compilers support variadic macros nowadays

I believe those weren't part of the standard until C99 (please correct 
me if I'm wrong).. so it falls under the same area as // comments and 
declare-variables-anywhere. Until Allegro starts requiring C99 compilers 
(or at least takes advantage of them by checking some defines that 
should exist), you can't do it.

- Kitty Cat

On Monday 02 August 2004 11:43, Sam Hocevar wrote:
>    Most compilers support variadic macros nowadays, so we could use
> something like that:
> 
>    #define main(a,b...) \
>       _mangled_main(a,##b); \
>       int main(int argc, char *argv[]) \
>       { \
>          int (*real_main) (int, char*[]) = \
>             (int (*) (int, char*[])) _mangled_main; \
>          __crt0_argc = argc; \
>          __crt0_argv = argv; \
>          return (*real_main)(argc, argv); \
>       }; \
>       int _mangled_main(a,##b)

Interesting. How widely supported is this? From the look and general 
usefulness, I'd suspect it to be a GNU extension. If both GCC and MSVC 
support this, that would be great.
This (probably) leaves compilers like BCC and Watcom in the dark though 
(but how many people actually use Allegro with those?)

Evert

> 
>    This does not require END_OF_MAIN, and works whatever the definition
> of main. It requires that main() is not prototyped after <allegro.h> has
> been #included, though.

Evert Glebbeek wrote:
> In that case, if we have a #define al_main main on platforms that don't 
> require main maming, I'd prefer to just have a main() as we do now and 
> modify that.

Unfortunately, because main can have varying arguments (main(), 
main(void), main(int argc), main(int argc, char *argv[]), main(int argc, 
char *argv[], <something> argz)), you can't know what the programer has 
made and thus what to pass. The only way you could handle that would be 
to create a macro that handles variable arguments, but those are only in 
C99 (I'm not even sure C++ can do them).

- Kitty Cat

On Monday 02 August 2004 11:58, Chris wrote:
> Unfortunately, because main can have varying arguments (main(), 
> main(void), main(int argc), main(int argc, char *argv[]), main(int argc, 
> char *argv[], <something> argz)), you can't know what the programer has 
> made and thus what to pass. The only way you could handle that would be 
> to create a macro that handles variable arguments, but those are only in 
> C99 (I'm not even sure C++ can do them).

I think the standard says main(void) and main(int, char**) are valid, but 
someone may want to check that.
Allegro currently works around this nicely by using a function pointer and 
a cast, as in Sam's example. We have basically

/* in user code, after Allegro's name mangling */
int _mangled_main(...)
{
}

/* in Allegro code */
int main(int argc, char *argv[]) 
{ 
   int (*real_main) (int, char*[]) = (int (*) (int, char*[]))_mangled_main;
   /* stuff */
   return (*real_main)(argc, argv); 
}

This is why I think that renaming the user's main and define our own (as 
SDL does), combined with a function pointer to work around the possible 
different definitions of main (what Allegro already does now) can be a way 
to work around the need for END_OF_MAIN() on Windows. Don't know how to 
work around the OS X problem though... :(

The problem with doing something more fancy than renaming main() to 
something else, like including code with it, is that it will do what we 
want for the actual main function. It will blow up in our faces in the 
case of the element of a struct being named main though (which is not an 
issue right now).

It'd suck if we can figure out a way to eliminate END_OF_MAIN() on all 
platforms except MacOS X.

Evert

On Mon, Aug 02, 2004, Evert Glebbeek wrote:

> Interesting. How widely supported is this? From the look and general 
> usefulness, I'd suspect it to be a GNU extension. If both GCC and MSVC 
> support this, that would be great.

   They both do. The only one I had problems with was Borland's (but I
only have version 6; maybe people who own more recent versions might
check that).

   By the way, I have used the previously mentioned #define for the
Debian version of Allegro, to avoid the necessity for alleg_unsharable.a
which was breaking prelinking (because of undefines weak symbols).
To maintain compatibility with binaries linked with classic Allegro
versions, (which don't contain a main() routine) I have added the
following code to src/unix/umain.c:

/* main:
 *  Replacement for main function (capture arguments and call real main).
 */
int main(int argc, char *argv[]) {
   int (*real_main) (int, char*[]);
   void **_mangled_main_address;
   char *program = argv[0] ? argv[0] : "program";
   fprintf(stderr, "%s: built with a non-Debian Allegro, running glue code\n",
           program);
   _mangled_main_address = dlsym(NULL, "_mangled_main_address");
   if(_mangled_main_address == NULL) {
      fprintf(stderr, "%s: mangled main address not found\n", program);
      return -1;
   }
   real_main = (int (*) (int, char*[])) *_mangled_main_address;
   __crt0_argc = argc;
   __crt0_argv = argv;
   fprintf(stderr, "%s: everything went fine\n", program);
   return (*real_main)(argc, argv);
}

-- 
Sam.

On Monday 02 August 2004 13:48, Sam Hocevar wrote:
>    They both do. The only one I had problems with was Borland's (but I
> only have version 6; maybe people who own more recent versions might
> check that).

I'm curious to hear about that, personally...

>    By the way, I have used the previously mentioned #define for the
> Debian version of Allegro, to avoid the necessity for alleg_unsharable.a
> which was breaking prelinking (because of undefines weak symbols).

What was the problem exactly?
Can you try the most recent WIP? It adds an allegro_icon weak symbol to the 
library to set the X11 icon. I haven't heard about problems with this yet, 
but the WIP is somewhat recent.

> To maintain compatibility with binaries linked with classic Allegro
> versions, (which don't contain a main() routine) I have added the
> following code to src/unix/umain.c:

If all goes well (that is, there are no further problems with my new 
get_executable_filename), then we no longer even need a magic main on 
*nix, and we can delete umain.c from the sourcetree.
This would be an ideal situation IMO.

Evert

On Mon, Aug 02, 2004, Evert Glebbeek wrote:
> On Monday 02 August 2004 13:48, Sam Hocevar wrote:
> >    They both do. The only one I had problems with was Borland's (but I
> > only have version 6; maybe people who own more recent versions might
> > check that).
> 
> I'm curious to hear about that, personally...

   Sorry, I checked again, it was not version 6. My CD is from
C++Builder 5.0.

> What was the problem exactly?
> Can you try the most recent WIP? It adds an allegro_icon weak symbol to the 
> library to set the X11 icon. I haven't heard about problems with this yet, 
> but the WIP is somewhat recent.

   Underfined weak symbols make it impossible to prelink a binary
because those symbols are only resolved at runtime. Also, you
cannot strip symbols from the main executable. And it is also not
possible to make real library wrappers: if I create a libfoo library
that links against allegro, I have to link the final program with
-lalleg_unsharable even if it only uses symbols from libfoo and not
allegro.

   I believe it is much cleaner to have an allegro_set_icon() function
in the API than to depend on the presence of an allegro_icon symbol in
the main program.

> > To maintain compatibility with binaries linked with classic Allegro
> > versions, (which don't contain a main() routine) I have added the
> > following code to src/unix/umain.c:
> 
> If all goes well (that is, there are no further problems with my new 
> get_executable_filename), then we no longer even need a magic main on 
> *nix, and we can delete umain.c from the sourcetree.
> This would be an ideal situation IMO.

   That would be nice indeed, though I'd have done it the GTK+ way:
having allegro_init() accept argc and argv as arguments, or 0/NULL, so
that no ugly /proc parsing is necessary (on my grsec laptop, non-root
users cannot browse /proc except for specific cases).

Regards,
Sam.
-- 
Sam Hocevar <sam@...> <http://sam.zoy.org/>

      Racism is so gay! How could you ever be racist?

On Mon, 2004-08-02 at 13:48 +0200, Sam Hocevar wrote:
> On Mon, Aug 02, 2004, Evert Glebbeek wrote:
> 
> > Interesting. How widely supported is this? From the look and general 
> > usefulness, I'd suspect it to be a GNU extension. If both GCC and MSVC 
> > support this, that would be great.
> 
>    They both do. The only one I had problems with was Borland's (but I
> only have version 6; maybe people who own more recent versions might
> check that).
> 
>    By the way, I have used the previously mentioned #define for the
> Debian version of Allegro, to avoid the necessity for alleg_unsharable.a
> which was breaking prelinking (because of undefines weak symbols).
> To maintain compatibility with binaries linked with classic Allegro
> versions, (which don't contain a main() routine) I have added the
> following code to src/unix/umain.c:
> 

You are the Debian maintainer? Great to have you on this list! I love
Debian :) (Although I never get to use its Allegro packages, having
several CVS and release candidate versions installed already.) I
remember, some years ago someone else was the Debian maintainer for
Allegro, don't recall the name though.

Anyway, I have nothing useful to say in this post..

-- 
Elias Pschernig

On Mon, Aug 02, 2004, Elias Pschernig wrote:

> You are the Debian maintainer? Great to have you on this list! I love
> Debian :) (Although I never get to use its Allegro packages, having
> several CVS and release candidate versions installed already.) I
> remember, some years ago someone else was the Debian maintainer for
> Allegro, don't recall the name though.

   Yes, I took over maintainership in '02 when Eduard Bloch orphaned the
packages. I am currently packaging the 4.1.x versions because I was fed
up with backporting fixes.

Regards,
-- 
Sam.

On Monday 02 August 2004 14:37, Sam Hocevar wrote:
>    Underfined weak symbols make it impossible to prelink a binary
> because those symbols are only resolved at runtime. Also, you
> cannot strip symbols from the main executable. And it is also not
> possible to make real library wrappers: if I create a libfoo library
> that links against allegro, I have to link the final program with
> -lalleg_unsharable even if it only uses symbols from libfoo and not
> allegro.
> 
>    I believe it is much cleaner to have an allegro_set_icon() function
> in the API than to depend on the presence of an allegro_icon symbol in
> the main program.

I can add a set_window_icon() function anyway (in fact, I may), but this is 
currently not needed in Windows. I'd rather not have it more difficult to 
set the icon in X than it is in Windows.
The current code allows for the possibility that weak symbols are not 
available and will try to use a constructor function to point the (in that 
case) non-weak symbol allegro_icon to user supplied data.

In case you're wondering, the way this is currently done is through the 
xfixicon.sh script. It outputs a .c file given a source image (say, .xpm) 
that will re-define the weak allegro_icon to point to the (inlined) pixmap 
data if weak symbols can be used, or point it there using a constructor 
function if it cannot define a weak symbol but can use a constructor.

Would this be something that could cause a problem? If not, I can simply 
change the current scheme to always use a constructor function and never 
use a weak symbol.

Evert

On Monday 02 August 2004 14:37, Sam Hocevar wrote:
>    That would be nice indeed, though I'd have done it the GTK+ way:
> having allegro_init() accept argc and argv as arguments, or 0/NULL, so
> that no ugly /proc parsing is necessary (on my grsec laptop, non-root
> users cannot browse /proc except for specific cases).

We can't change the prototype for allegro_init(), although it would be 
possible to add a function to the API that explicitly passes argc and argv 
to Allegro, as Peter suggested. If not called, the current (well, current 
in my local tree anyway) scheme using procfs and ps as fallback is used. 
If called, the argv[0] can be used in preference to ps.
Although I feel this is starting to be a bit much for a function that is 
likely little-used anyway. ;)

Evert

On Mon, Aug 02, 2004, Evert Glebbeek wrote:

> We can't change the prototype for allegro_init(), although it would be 
> possible to add a function to the API that explicitly passes argc and argv 
> to Allegro, as Peter suggested. If not called, the current (well, current 
> in my local tree anyway) scheme using procfs and ps as fallback is used. 
> If called, the argv[0] can be used in preference to ps.
> Although I feel this is starting to be a bit much for a function that is 
> likely little-used anyway. ;)

   I fully agree. I'd say drop it: applications know how they are called
anyway, don't they?

-- 
Sam.

On Mon, Aug 02, 2004, Evert Glebbeek wrote:

> In case you're wondering, the way this is currently done is through the 
> xfixicon.sh script. It outputs a .c file given a source image (say, .xpm) 
> that will re-define the weak allegro_icon to point to the (inlined) pixmap 
> data if weak symbols can be used, or point it there using a constructor 
> function if it cannot define a weak symbol but can use a constructor.
> 
> Would this be something that could cause a problem? If not, I can simply 
> change the current scheme to always use a constructor function and never 
> use a weak symbol.

   Nothing critical; it's just against the Debian policy to have
undefined weak symbols in libraries, for the reasons I mentioned (plus
it prevents some other things such as dlopen("liballegro.so")). In
general, having a library's headers add symbols to the executable is bad
style.

-- 
Sam.

On Monday 02 August 2004 15:25, Sam Hocevar wrote:
>    I fully agree. I'd say drop it: applications know how they are called
> anyway, don't they?

They know how, but they don't know where they are in the filesystem.
The main use of get_executable_name is to find the path where the 
executable is in order to locate the game data files.
This makes sense in Windows, but not much in *nix anyway, at least for 
well-behaved applications. So it's use is limited.
Having this functionality eases porting Windows programs though.

Evert

On Monday 02 August 2004 15:53, Sam Hocevar wrote:
>    Nothing critical; it's just against the Debian policy to have
> undefined weak symbols in libraries, for the reasons I mentioned (plus
> it prevents some other things such as dlopen("liballegro.so")). In
> general, having a library's headers add symbols to the executable is bad
> style.

Ok, I'll change it to use a constructor always and not output a weak 
symbol.

Evert

On Mon, 2 Aug 2004, Evert Glebbeek wrote:

> On Monday 02 August 2004 15:25, Sam Hocevar wrote:
>>    I fully agree. I'd say drop it: applications know how they are called
>> anyway, don't they?
>
> They know how, but they don't know where they are in the filesystem.
> The main use of get_executable_name is to find the path where the
> executable is in order to locate the game data files.
> This makes sense in Windows, but not much in *nix anyway, at least for
> well-behaved applications. So it's use is limited.
> Having this functionality eases porting Windows programs though.

What about adding these two functions:

get_data_path()
- returns path where datafiles are located (path with executable on Win, 
/usr/share/XY on *nix)

get_state_path()
- returns path where game state files (= saves, modifiable config files, 
etc.) should be stored (again path with executable on Win, ~/.XY on *nix)

Of course that brings the problem what XY is/should be :-)

Have a nice day.

Stepan Roh

Stepan Roh:
> What about adding these two functions:

> get_data_path()
> - returns path where datafiles are located (path with executable on Win, 
> /usr/share/XY on *nix)

According to FHS, that should be /usr/share/games/XY, and wouldn't it also need
to support /usr/local hierarchy? And what if a user installed the game to his
home dir?

> get_state_path()
> - returns path where game state files (= saves, modifiable config files, 
> etc.) should be stored (again path with executable on Win, ~/.XY on *nix)

> Of course that brings the problem what XY is/should be :-)

Yeah, I think functions like these should be left for users to implement.

I've got one that works like this:

primary keywords:

game
tool

(There are differences to where files should be stored in both Windows and
Linux depending on whether the application is a game or not.)

secondary keywords:

bin
doc
data (static data)
var (variable data)
user (home dir)

usage:

find_file("game/data/foo");

In Linux, this resolves to either /usr/share/games/XY/foo,
/usr/local/share/games/XY/foo or "exe_parent"/data/foo, depending on path to
executable (I only plan to support Linux, so I use /proc/self).

--
Daniel Schlyder
http://bitblaze.com/

> We should try it with MSVC I guess. It looks like normal main() just
> works in Windows. Oh, and I'm cc-ing this to Eric, he is the windows
> expert, maybe he remembers a reason why END_OF_MAIN is needed there.

IIRC this was needed for RSXNTDJ, because the linker was using the presence
of Winmain to decide which type of application (GUI vs console) to build.  I
think this is not really needed for MinGW/MSVC/BCC, because they all allow
the user to specify the type at link-time (see the Allegro makefiles).

However the latter assertion should be carefully checked.  Also note that
making the change means that Allegro would deviate from the canonical
practice of the last 15 years on Windows.

P.S.: for a previous discussion about all this stuff, see
http://sourceforge.net/mailarchive/message.php?msg_id=5661074

--
Eric Botcazou

On Mon, 2 Aug 2004, Daniel Schlyder wrote:

> Stepan Roh:
>> What about adding these two functions:
>
>> get_data_path()
>> - returns path where datafiles are located (path with executable on Win,
>> /usr/share/XY on *nix)
>
> According to FHS, that should be /usr/share/games/XY, and wouldn't it also need
> to support /usr/local hierarchy? And what if a user installed the game to his
> home dir?
>
>> get_state_path()
>> - returns path where game state files (= saves, modifiable config files,
>> etc.) should be stored (again path with executable on Win, ~/.XY on *nix)
>
>> Of course that brings the problem what XY is/should be :-)
>
> Yeah, I think functions like these should be left for users to implement.

I think get_executable_name() should be dropped w/o replacement or with 
something like your find_file() (which I removed from this post :-) ) as a 
replacement.

Could be (in the spirit of find_allegro_resource(), but smaller):

int find_user_resource(char *dest, const char *resource, int type, int 
size);

where type is either DATA or STATE or whatever you like

Places where such resource is located in are configured with:

add_user_resource_dir(const char *dir, int type);

Default resource dirs (last ones to be searched) are program dir for 
Windows and current dir for *nix.

In main() programmers write:

#ifdef DATA_DIR
add_user_resource_dir(DATA_DIR, DATA);
#endif
#ifdef STATE_DIR
add_user_resource_dir(STATE_DIR, STATE);
#endif

Values of *_DIR are supplied by some config.h created during build 
process on *nix and undefined on Windows.

Have a nice day.

Stepan Roh

Stepan Roh:
> In main() programmers write:

> #ifdef DATA_DIR
> add_user_resource_dir(DATA_DIR, DATA);
> #endif
> #ifdef STATE_DIR
> add_user_resource_dir(STATE_DIR, STATE);
> #endif

> Values of *_DIR are supplied by some config.h created during build 
> process on *nix and undefined on Windows.

The macro for single user variable game data should also be defined on Windows:

2000/XP: C:\Documents and Settings\USER\My Documents\My Games\PROGRAM
     9x: C:\My Documents\My Games\PROGRAM

(The "My Games" dir was introduced in Windows 2000 or XP, I think, but can be
created by the function if it doesn't exist.)


It would also be nice to have the macro for shared variable game data (

   2000/XP: C:\Documents and Settings\All Users\Shared Documents\Games\PROGRAM
98/98SE/Me: C:\WINDOWS\All Users\Games\PROGRAM

) but I don't think this is supported well enough, because:

1. I don't know if the "All Users" dir exists on Windows 95.

2. Getting a meaningful value out of CSIDL_COMMON_DOCUMENTS requires a DLL
that doesn't come with 98 by default (not sure about ME), and I still only got
a blank return value when I had made sure I had the required DLL (but that's
probably my fault).

3. Windows XP incorrectly returns "C:\Documents and Settings\All
Users\Documents\PROGRAM" (ie. "Documents" instead of "Shared Documents" - could
it be a problem with MinGW?).

Too bad, since I assume limited users can't save to C:\Program Files
hierarchy. Maybe not a real issue, though. (Oh, and I think I may have invented
the "Games" dir just to be more in line with "My Games". :))

There's documents out there that describe which paths one should use. Lots of
commercial games use the home dir these days, never seen any using the
"shared..." dir, though. Maybe because of the same problems I had.

--
Daniel Schlyder
http://bitblaze.com/

On August 2, 2004 01:47 am, Thomas Fjellstrom wrote:
[snip]
>
> 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. :)
>

Actually, its just silly ;) Noticed another problem last night while falling 
asleep that'll make it totally useless. :)

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

Daniel Schlyder wrote:
> The macro for single user variable game data should also be defined on Windows:
> 
> 2000/XP: C:\Documents and Settings\USER\My Documents\My Games\PROGRAM
>      9x: C:\My Documents\My Games\PROGRAM
> 
> (The "My Games" dir was introduced in Windows 2000 or XP, I think, but can be
> created by the function if it doesn't exist.)

I really, really don't like this idea. I prefer all my game data and 
config files to be in the same directory as the game. And since most 
Allegro programs are simply "unzip, (compile}, run", having end users 
have to move data around to simply get the game to run (or forcing the 
programmer to make an installer), is very bad, IMO. As well, it would 
make uninstallation harder since you now have to go hunting around for 
extra datafiles instead of just deleting the directory.

The only reason having config files in ~/.something is acceptable in 
Linux/Unix is that most people using these systems use the command line 
anyway.. so it's the difference of typing 'nano 
<path_to_program>/config.cfg' or 'nano ~/.program/config.cfg'. On 
Windows however, this becomes much more complex since there is no home 
directory shortcut like ~ in Unix, and most users aren't savvy enough to 
know where to look.. plus they rarely use the command line so they'd 
have to stumble around explorer.

Allegro games generally aren't professional level games with installers, 
uninstallers, extensive in-game config systems, etc.. so having it 
available to the normal programmer will just confuse things a lot more 
for both him and the end user. And the games that do reach that level of 
completion can still do it themselves since Allegro doesn't do anything 
to stop it. I just don't think it should be encouraged.

- Kitty Cat

Chris:
> Daniel Schlyder wrote:
>> The macro for single user variable game data should also be defined on Windows:
>> 
>> 2000/XP: C:\Documents and Settings\USER\My Documents\My Games\PROGRAM
>>      9x: C:\My Documents\My Games\PROGRAM
>> 
>> (The "My Games" dir was introduced in Windows 2000 or XP, I think, but can be
>> created by the function if it doesn't exist.)

> I really, really don't like this idea.

Well, I wasn't advocating this functionality be added to Allegro, just that if
it was, there are standard directories one should strive to support also on
Windows, instead of just dumping everything in "Program Files."

> I prefer all my game data and config files to be in the same directory as the
> game. And since most Allegro programs are simply "unzip, (compile}, run",
> having end users have to move data around to simply get the game to run (or
> forcing the programmer to make an installer), is very bad, IMO.

Yes, the programmer would obviously have to make an installer (and
uninstaller). In my perfect world every game would have this, but I don't want
to force every Allegro programmer to make one. Of course, you could always
just not use those particular functions.

> As well, it would make uninstallation harder since you now have to go hunting
> around for extra datafiles instead of just deleting the directory.

No, all you'd need to do would be to click the uninstall icon.

> The only reason having config files in ~/.something is acceptable in
> Linux/Unix is that most people using these systems use the command line
> anyway.. so it's the difference of typing 'nano <path_to_program>/config.cfg'
> or 'nano ~/.program/config.cfg'. On Windows however, this becomes much more
> complex since there is no home directory shortcut like ~ in Unix, and most
> users aren't savvy enough to know where to look.. plus they rarely use the
> command line so they'd have to stumble around explorer.

Hum, I don't understand why you mention the command line. All the novice PC
users I've helped set up computers for, heavily used the "My Documents" folder.
It's one of the top items in Explorer and on the Start menu.

> Allegro games generally aren't professional level games with installers,
> uninstallers, extensive in-game config systems, etc..
> so having it available to the normal programmer will just confuse things a
> lot more for both him and the end user. And the games that do reach that
> level of completion can still do it themselves since Allegro doesn't do
> anything to stop it. I just don't think it should be encouraged.

Please don't blow this out of proportions. It takes about five minutes to
create a professionally looking installer using, for example, Inno Setup, and I
don't see how it could possibly confuse the end user. To the contrary, I would
think most of them would prefer an installer to an archive that they might not
know how to unpack, or where to, or what to do next.

--
Daniel Schlyder
http://bitblaze.com/

Daniel Schlyder wrote:
> Hum, I don't understand why you mention the command line. All the novice PC
> users I've helped set up computers for, heavily used the "My Documents" folder.
> It's one of the top items in Explorer and on the Start menu.

Besides having a folder called "My Documents" holding game data and 
config info (a misnomer if I ever saw one), it adds nothing but 
confusion. Like if a game says to edit the config file, one would 
obviously ask.. "Where's the config file?" It'd be a lot easier and 
simpler to say "where you extracted the program" than "look in 
C:\Documents and Settings\<your user name>\My Documents\Application 
Data\(program name)". Microsoft should be shot for having a directory 
structure like that. Of course it doesn't help that most Windows users 
don't even know that that's partly the same as clicking My Documents in 
the start menu.

> Please don't blow this out of proportions. It takes about five minutes to
> create a professionally looking installer using, for example, Inno Setup, and I
> don't see how it could possibly confuse the end user. To the contrary, I would
> think most of them would prefer an installer to an archive that they might not
> know how to unpack, or where to, or what to do next.

Windows users might prefer installers so that it hides the nitty gritty 
details that it's throwing files around every which way, but as a Linux 
user, I personally don't like installers for that very reason (besides 
being plain uncommon). If something goes wrong and I need to uninstall 
it, I'd like to be able to just run 'rm -rf <directory>'.. not another 
program given by the possibly buggy installer/main program and hope it 
doesn't choke on something. It's also very counter-intuitive to do for 
source distributions.

That's not to say I think installers are inherently bad. I just think 
that having an (un)installer is a poor reason to be able to throw files 
anywhere on the drive.

- Kitty Cat

On Monday 02 August 2004 20:48, Stepan Roh wrote:
> I think get_executable_name() should be dropped w/o replacement or with 
> something like your find_file() (which I removed from this post :-) ) as 
a 
> replacement.

It can't really be dropped because of API compatibility. However, a 
function that locates a file might be useful.

> Could be (in the spirit of find_allegro_resource(), but smaller):
> 
> int find_user_resource(char *dest, const char *resource, int type, int 
> size);
> 
> where type is either DATA or STATE or whatever you like
> 
> Places where such resource is located in are configured with:
> 
> add_user_resource_dir(const char *dir, int type);
> 
> Default resource dirs (last ones to be searched) are program dir for 
> Windows and current dir for *nix.

I think something like this could work (in fact, I use something comparable 
in my own programs), but I'm not sure if it is something that should be 
build into Allegro.

> In main() programmers write:
> 
> #ifdef DATA_DIR
> add_user_resource_dir(DATA_DIR, DATA);
> #endif
> #ifdef STATE_DIR
> add_user_resource_dir(STATE_DIR, STATE);
> #endif
> 
> Values of *_DIR are supplied by some config.h created during build 
> process on *nix and undefined on Windows.

If they're undefined on Windows, then most users aren't going to bother 
using them. If we want people to write platform independent code, then we 
need them to be able to do so without too much trouble.
I personally probably wouldn't bother with similar typedefs in my code if 
they were needed to make my program do something particular in Windows. ;)

As an analogy, consider the ALLEGRO_VRAM_SINGLE_SURFACE define: this has to 
be used to make things like double buffering or tripple buffering work in 
Windows as well as X. Up to recently, not even Allegro's examples and demo 
game used to check for this.

Evert

> Ok, I'll change it to use a constructor always and not output a weak 
> symbol.

I've committed the attached patch. It removes the weak symbol declaration 
of allegro_icon and makes the outputfile produced by xfixicon.sh always 
use Allegro's constructor function defines.
It also adds a check to see if Allegro indeed has X11 support, so that the 
file can be safely included in the list of sourefiles even if X is not 
present or if UNIX is not used.

Evert

A bit late, but I just had to comment on this mail.

Chris:
> Besides having a folder called "My Documents" holding game data and
> config info (a misnomer if I ever saw one), it adds nothing but
> confusion.

Err, it's called "My Documents" because, well, it's the directory where you
store your documents. I really don't see how that can be confusing. Where else
would it be more appropriate to store variable game data that is only meant for
a specific user? Are you also saying that one shouldn't store this kind of data
under home dir on Linux?

> Like if a game says to edit the config file, one would obviously ask..
> "Where's the config file?" It'd be a lot easier and simpler to say "where you
> extracted the program" than "look in C:\Documents and Settings\<your user
> name>\My Documents\Application Data\(program name)". Microsoft should be shot
> for having a directory structure like that.

Windows users mostly don't extract programs, they install them. And you say
"look in My Documents\My Games\(program name)" or just "My Documents\(program
name)". The "Application Data" folder is not placed under "My Documents" and it
is not meant for games.

> Of course it doesn't help that most Windows users don't even know that that's
> partly the same as clicking My Documents in the start menu.

Are you sure you speak for most Windows users? At least, this hasn't been my
experience.

> Windows users might prefer installers so that it hides the nitty gritty
> details that it's throwing files around every which way, but as a Linux 
> user, I personally don't like installers for that very reason (besides 
> being plain uncommon).

What about RPMs, etc.? I thought those were very common.

> If something goes wrong and I need to uninstall it, I'd like to be able to
> just run 'rm -rf <directory>'.. not another program given by the possibly
> buggy installer/main program and hope it doesn't choke on something.

Agreed. Luckily, programs with buggy installers are rare.

> It's also very counter-intuitive to do for source distributions.

Which, of course, is not a valid argument against doing it for binary
distributions.

> That's not to say I think installers are inherently bad. I just think 
> that having an (un)installer is a poor reason to be able to throw files 
> anywhere on the drive.

When you put it that way, it sounds very negative. You don't throw files
anywhere on the drive, you copy them according to the OS standard.

--
Daniel Schlyder
http://bitblaze.com/

On Monday 09 August 2004 5:47 pm, Daniel Schlyder wrote:
> What about RPMs, etc.? I thought those were very common.

RPM is a Package Manager. The difference between this and an installer is that 
RPM is an external tool which notes where every file is placed and correctly 
removes them all. Classical uninstallers are part of the application, 
proprietary, and not well tested.

> When you put it that way, it sounds very negative. You don't throw files
> anywhere on the drive, you copy them according to the OS standard.

I still like the idea that I can easily find all the files in one place and 
not have to hunt too much for them. This is, of course, failing a decent 
uninstaller. And I don't trust Windows uninstallers, because many leave 
registry entries lying around and such.

-- 
Regards,
Ryan Patterson <mailto:rpatters@...>

Daniel Schlyder wrote:
> Err, it's called "My Documents" because, well, it's the directory where you
> store your documents. I really don't see how that can be confusing.

Because to me, Documents = text files (txt, doc, etc). Configuration 
data is config/init files (cfg, ini, etc).


> Where else
> would it be more appropriate to store variable game data that is only meant for
> a specific user?

What ZDoom (a Win32 port of Doom) does is store the config data in 
zdoom-<username>.ini in the program's directory. Originally, it did go 
where it was "supposed to", but too many people complained because they 
couldn't find it.

 > Are you also saying that one shouldn't store this kind of data
> under home dir on Linux?

As I said, most Linux users are proficient with the command line.. 
moreso than most Windows users. Plus, Unix has the home dir shortcut ~/ 
followed by ".<program>". Windows does not do this. That said, I 
wouldn't mind at all if Linux programs kept config data in their own 
directory.

> Windows users mostly don't extract programs, they install them. And you say
> "look in My Documents\My Games\(program name)" or just "My Documents\(program
> name)". The "Application Data" folder is not placed under "My Documents" and it
> is not meant for games.

Right, my mistake. Still, I used Windows until about 6 months or so 
ago.. and I've never heard or seen a "My Documents\My Games" folder.

>>Windows users might prefer installers so that it hides the nitty gritty
>>details that it's throwing files around every which way, but as a Linux 
>>user, I personally don't like installers for that very reason (besides 
>>being plain uncommon).
> 
> What about RPMs, etc.? I thought those were very common.

Somewhat common maybe, but also troublesome. I've heard of a lot of 
people having trouble with RPMs.

>>It's also very counter-intuitive to do for source distributions.
> 
> Which, of course, is not a valid argument against doing it for binary
> distributions.

Considering most Allegro users opt for source distributions, since 
that's really the only way to have a cross-platform distro, I think it's 
still relevant. Sure, some also release Windows binaries but it'd just 
be more work for the programmer to do.

>>That's not to say I think installers are inherently bad. I just think 
>>that having an (un)installer is a poor reason to be able to throw files 
>>anywhere on the drive.
> 
> When you put it that way, it sounds very negative. You don't throw files
> anywhere on the drive, you copy them according to the OS standard.

It sounds negative, because (to me) it is negative. And I'd be wary of 
follow an OS's standard when that OS is known to break standards.. 
including its own.

- Kitty Cat

On Aug 9, 2004, at 6:47 PM, Daniel Schlyder wrote:
>> Of course it doesn't help that most Windows users don't even know 
>> that that's
>> partly the same as clicking My Documents in the start menu.
>
> Are you sure you speak for most Windows users? At least, this hasn't 
> been my
> experience.
>

Without trying to be insulting or saying ALL Windows users are so 
ignorant, that has been my experience also. Most Windows users I have 
encountered don't really understand the way their files are organized 
in a hierarchical file system, with directories and files in other 
directories. At most they know where to click to access certain things.

(A couple years ago I had a job installing cable modems. So every day 
I'd go to 4 or 5 houses and run cable and then talk to the people and 
see their computer and if necessary teach them how to use the cable 
modem. It was pretty sad how completely ignorant most computer using 
people are about computers. What I think was also sad is that nearly 
everyone ran Windows. During about a year of seeing 4 or 5 computers a 
day, I saw maybe 5 Macs (all running OS 9, even though OS 10 was out) 
and 2 machines running Linux.)

Mike Benfield