gamedevlists-general — List for discussing general game development issues

RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

To all intents and purposes, it required hardware T&L support.


_____________________________________
andrew grant | programmer | climax brighton
ag...@cl... - www.climax.co.uk




> -----Original Message-----
> From: Brian Hook [mailto:ho...@py...] 
> Sent: 04 December 2003 21:58
> To: gam...@li...
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> > back in 1999 not many developers other than id could get away with 
> > telling their publisher they intended to release a game 
> which required 
> > hardware T&L support :)
> 
> For the record, Q3 did not require hardware T&L support.  id required 
> working OpenGL drivers, that was it.
> 
> Brian
> 
> 

RE: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

> back in 1999 not many developers other than id could get away with
> telling their publisher they intended to release a game which
> required hardware T&L support :)

For the record, Q3 did not require hardware T&L support.  id required 
working OpenGL drivers, that was it.

Brian

RE: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

> I agree the registry isn't the place to store the data, but neither
> is the game install folder. Anything you need to save from your
> game and that doesn't ask the user for a path should go into the
> whatever's returned by SHGetFolderLocation(.., CSIDL_APPDATA, ..);

So what's the accepted wisdom now on use SHGetSpecialFolderLocation() 
vs. GetWindowsDirectory(), GetSystemDirectory() and getenv( "HOMEPATH" 
)?

Brian

Re: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

> [a] One can have many independent instances of the application on a
> single machine, each with different preferences;

That's great, except in many cases most users don't like/want/know 
about that.

> [b] The user can edit preferences if the application malfunctions,
> which is impossible in a scheme where the application itself is the
> only entity that can manipulate the preferences file;

That's quite true.  Except now you've committed to a plain text file, 
which might be bad if you have to store binary information for 
whatever reason (yeah, you could convert to 7-bit ASCII...bleh).

> [c] Users can send or receive preferences files, or disucss
> specific named settings, via e-mail or web pages;

Yes.  Although technically you can do that with a Windows registry...

> [d] Settings in the preferences file can correspond to an
> application's scripting system -- so that the preferences file is
> nothing more than a batch of scripting commands that can otherwise
> be entered at run-time in the application itself (as in a console
> window for a video game);

Yep.

> [e] Settings persist after clean install of operating system;

Yep.

> [f] Application and settings can be stored on a CD-ROM or portable
> disk or flash-memory device, and one can take it to someone else's
> computer and operate the application without doing an
> "installation" or polluting their computer with any files
> whatsoever; (I bring my prototype applications to a friend's house
> for demonstration on my keychain USB memory device, and execute
> directly from the keychain!)

Yep.

> Maybe I'm hard-core, but I think everything an application needs to
> operate, short of the absolutely guaranteed resources of the
> operating system, should be packaged with the application -- and
> totally portable.

Unix used to be like that, and most applications on DOS used to be 
like that -- the good old days.  In fact, most Unix applications were 
just an executable and didn't even have external crap associated with 
them.  Today, even the most trivial Windows application seems to 
require numerous INI and DLL files.

I'm in violent agreement with you.  I don't like the Windows registry, 
it seriously pisses me off in fact, however it is kind of a de facto 
standard for preference storage and does have a couple (albeit minor) 
benefits.  IT types like it simply because users don't know enough to 
get in and muck it up.  Also, I believe you can do remote registry 
queries under NT.

Standardized locations for everything is a nice thing, but whether 
it's worth the gigantic problem that the registry presents is 
questionable.

That said, I prefer files, and will support files-as-preferences on 
Windows, but supporting the registry will probably be a requirement no 
matter what.  On OS X, it's kind of the best of both worlds -- your 
preferences ARE files, and they're XML as well so they can be edited 
directly.

> or somehow the application disappears from the computer without un-
> install ever happening, leaving tons of scattered junk behind.

That's my biggest pet peeve -- I shouldn't HAVE to uninstall, I should 
just be able to delete a directory and have it go away.  Such a simple 
thing, but yet Windows still doesn't get it.

I'm also aghast at the sheer # of files that most applications and 
games require for installation into /windows/system32 and /windows, 
including game specific DLLs.  I have NO idea why developers insist on 
putting game specific DLLs in global locations.

> Okay, I sympathize with the idea that putting everything in one
> place somehow seems more organized.  I dislike the idea of things
> being scattered around.  But I think it's perfectly good to put
> things in self-contained bundles that do not rely on any
> centralized thing or on scattered things.  It's very clean.

You must love OS X Application Bundles then?  I happen to think 
they're one of the coolest aspects of OS X.

> Okay, some of these ideas are radical, but I just wanted to share
> my own thoughts about preferences files.

Not THAT radical.  Just in the Windows world =3D)

Brian

RE: [email] RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

True, but aside from the fact many games these days run into gigs of data,
what happens the first time you need to patch it or something similar? It
all gets messy very quickly.

My stance is that any game you ship should go out of its way to provide the
most user-friendly experience possible. From properly supporting things like
multi-monitor and alt+tab to implementing workarounds for known driver bugs
or issues. You can add as many things as you like into the requirements or
readme section, but insisting people are logged in as an admin or stating X
glitch is a driver issue and you should hassle an IHV to fix it isn't likely
to win you many fans.

It's also debatable just how savvy the average gamer or parent is with
computer matters, many people encountering a game which doesn't appear to
work will most likely simply take it back.

_____________________________________
andrew grant | programmer | climax brighton
ag...@cl... - www.climax.co.uk








> -----Original Message-----
> From: Dan Thompson [mailto:da...@ar...] 
> Sent: 04 December 2003 21:37
> To: gam...@li...
> Subject: Re: [email] RE: [GD-General] A portable preferences library
> 
> 
> I'd say it stumbles, but doesn't *quite* fall down. Since 
> with Colin's scheme you can move games/apps around as 
> entities freely, you could (in theory), just move the whole 
> thing somewhere where little johhny *does* have access. 
> Actually the windows LUA compatibility stuff under XP does 
> this exact thing in the registry to anyone who tries to write 
> to HKLM - just copies it to HKCU and lets them do whatever 
> they want to it.
> 
> -Dan
> 
> ----- Original Message ----- 
> From: "Andrew Grant" <ag...@cl...>
> To: <gam...@li...>
> Sent: Thursday, December 04, 2003 1:14 PM
> Subject: [email] RE: [GD-General] A portable preferences library
> 
> 
> > >> I think multi-user systems is an antiquated concept.
> >
> > You're joking right?
> >
> > Also your scheme falls down the minute somebody without 
> write access 
> > to
> the
> > games folder attempts to play it. Something that's pretty 
> common these
> days
> > where Dad has to install the games little Johnny wants to 
> play on the
> family
> > PC. I'd be surprised if your approach makes it through QA of any 
> > publisher worth their salt.
> >
> > I agree the registry isn't the place to store the data, but 
> neither is 
> > the game install folder. Anything you need to save from 
> your game and 
> > that doesn't ask the user for a path should go into the whatever's 
> > returned by SHGetFolderLocation(.., CSIDL_APPDATA, ..);
> >
> >
> > _____________________________________
> > andrew grant | programmer | climax brighton ag...@cl... - 
> > www.climax.co.uk
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Colin Fahey [mailto:cp...@ea...]
> > > Sent: 04 December 2003 20:42
> > > To: gam...@li...
> > > Subject: Re: [GD-General] A portable preferences library
> > >
> > >
> > > 2003 December 4th
> > > Thursday
> > >
> > > I have used the following scheme for storing user 
> preferences for an 
> > > application:
> > >
> > > [1] A plain text file in the same directory as the executable,
> > >        with the extension *.txt rather than something else (like
> > >        *.ini);
> > >
> > > [2] The application, when launched, can determine the path of its
> > >       executable file, and thus the location of the corresponding
> > >       user preferences text file;
> > >
> > > [3] All aspects of reading the user preferences text file are
> > >       fault-tolerant; re-ordering, adding, removing fields will
> > >       have the least possible effect -- and field values are
> > >       similarly checked and clipped to sane limits.
> > >
> > > Security of the preferences is not an issue for my use of this 
> > > scheme.
> > >
> > > Benefits of this scheme:
> > >
> > >   [a] One can have many independent instances of the application
> > >         on a single machine, each with different preferences;
> > >
> > >   [b] The user can edit preferences if the application 
> malfunctions,
> > >         which is impossible in a scheme where the 
> application itself
> > >         is the only entity that can manipulate the 
> preferences file;
> > >
> > >   [c] Users can send or receive preferences files, or disucss
> > >         specific named settings, via e-mail or web pages;
> > >
> > >   [d] Settings in the preferences file can correspond to an
> > >         application's scripting system -- so that the preferences
> > >         file is nothing more than a batch of scripting commands
> > >         that can otherwise be entered at run-time in the
> > >         application itself (as in a console window for a video
> > >         game);
> > >
> > >   [e] Settings persist after clean install of operating system;
> > >
> > >   [f] Application and settings can be stored on a CD-ROM or
> > >         portable disk or flash-memory device, and one can
> > >         take it to someone else's computer and operate the
> > >         application without doing an "installation" or
> > >         polluting their computer with any files whatsoever;
> > >         (I bring my prototype applications to a friend's house
> > >         for demonstration on my keychain USB memory device,
> > >         and execute directly from the keychain!)
> > >
> > > Basically, I'm a strong believer of the settings following the 
> > > application around.  I think the old MacIntosh operating 
> system hid 
> > > a kind of directory system behind the application icon -- 
> with the 
> > > "resource fork" and "data fork", which was a pretty good idea 
> > > because it allowed data associated with a program to be 
> bound to the 
> > > program.  Thus, moving or copying the icon would assure that all 
> > > settings and data moved with it. It was a nice abstraction that 
> > > simplified the notion of "application" and reduced confusion when 
> > > moving it around.
> > >
> > > Maybe I'm hard-core, but I think everything an 
> application needs to 
> > > operate, short of the absolutely guaranteed resources of the 
> > > operating system, should be packaged with the application -- and 
> > > totally portable.  I should be able to run any application on 
> > > anyone's computer from my keychain memory device, without 
> adding any 
> > > files to their computer!
> > >
> > > I think multi-user systems is an antiquated concept.  But 
> if I must 
> > > support multiple users of a single application (as 
> opposed to each 
> > > user installing his or her own copy of the application), then 
> > > individual preferences files can be stored with the application. 
> > > "preferences_bob.txt", "preferences_joe.txt", etc.  Putting these 
> > > preferences anywhere else but with the application leads to
> > > potential pollution that might never go away.  Lots of
> > > irresponsible developers don't do a good job of
> > > un-installation -- or somehow the application disappears from
> > > the computer without un-install ever happening, leaving tons
> > > of scattered junk behind.
> > >
> > > I always thought the Windows registry was a disaster; it 
> encouraged 
> > > people to centralize critical information, and it has 
> been a source 
> > > of confusion and annoyance for users. Protecting the integrity of 
> > > this single trash heap is silly.
> > >
> > > Okay, I sympathize with the idea that putting everything in one 
> > > place somehow seems more organized.  I dislike the idea of things 
> > > being scattered around.  But I think it's perfectly good to put 
> > > things in self-contained bundles that do not rely on any 
> centralized 
> > > thing or on scattered things.  It's very clean.
> > >
> > > I think rather than pushing itself upon one's computer (like a 
> > > formal installation procedure), applications should be 
> passive and 
> > > the operating system should instead scan for applications upon
> > > boot-up. Thus, the "Start" menu is populated at boot time and
> > > is 100% in sync with available applications.  Applications
> > > can contain
> > > preferences about placement in the "Start" menu hierarchy,
> > > much like an application can propose its own icon.  The key
> > > is to eliminate the idea of "installation".
> > >
> > > Okay, some of these ideas are radical, but I just wanted 
> to share my 
> > > own thoughts about preferences files.
> > >
> > > --- Colin
> > >
> > > cp...@ea...
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SF.net Giveback Program. Does 
> > > SourceForge.net help you be more productive?  Does it help you 
> > > create better code?  SHARE THE LOVE, and help us help YOU!  Click 
> > > Here: http://sourceforge.net/donate/ 
> > > _______________________________________________
> > > Gamedevlists-general mailing list 
> > > Gam...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > > Archives: 
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> > >
> 
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program. Does 
> > SourceForge.net help you be more productive?  Does it help 
> you create 
> > better code?  SHARE THE LOVE, and help us help YOU!  Click Here: 
> > http://sourceforge.net/donate/ 
> > _______________________________________________
> > Gamedevlists-general mailing list 
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> Does SourceForge.net help you be more productive?  Does it 
> help you create better code?  SHARE THE LOVE, and help us 
> help YOU!  Click Here: http://sourceforge.net/donate/ 
> _______________________________________________
> Gamedevlists-general mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

Perhaps there are other reasons for that requirement (although I can't think
of them) but if that was the only one it smacks of a lack of planning. No
disrespect intended to anyone from Blizzard who's reading this ;)

Most developers won't even have that leeway anyway. The same as how back in
1999 not many developers other than id could get away with telling their
publisher they intended to release a game which required hardware T&L
support :)


_____________________________________
andrew grant | programmer | climax brighton
ag...@cl... - www.climax.co.uk





> -----Original Message-----
> From: Crosbie Fitch [mailto:cr...@cy...] 
> Sent: 04 December 2003 21:27
> To: gam...@li...
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> > From: Andrew Grant
> > Also your scheme falls down the minute somebody without 
> write access 
> > to the games folder attempts to play it. Something that's pretty
> > common these days
> > where Dad has to install the games little Johnny wants to
> > play on the family
> > PC. I'd be surprised if your approach makes it through QA of
> > any publisher worth their salt.
> 
> You could compare it with Blizzard's requirement for Warcraft 
> III players to be administrators (on W2K, etc.).
> 
> 

Re: [email] RE: [GD-General] A portable preferences library

[Dan T. <da...@ar...>]

I'd say it stumbles, but doesn't *quite* fall down. Since with Colin's
scheme you can move games/apps around as entities freely, you could (in
theory), just move the whole thing somewhere where little johhny *does* have
access. Actually the windows LUA compatibility stuff under XP does this
exact thing in the registry to anyone who tries to write to HKLM - just
copies it to HKCU and lets them do whatever they want to it.

-Dan

----- Original Message ----- 
From: "Andrew Grant" <ag...@cl...>
To: <gam...@li...>
Sent: Thursday, December 04, 2003 1:14 PM
Subject: [email] RE: [GD-General] A portable preferences library


> >> I think multi-user systems is an antiquated concept.
>
> You're joking right?
>
> Also your scheme falls down the minute somebody without write access to
the
> games folder attempts to play it. Something that's pretty common these
days
> where Dad has to install the games little Johnny wants to play on the
family
> PC. I'd be surprised if your approach makes it through QA of any publisher
> worth their salt.
>
> I agree the registry isn't the place to store the data, but neither is the
> game install folder. Anything you need to save from your game and that
> doesn't ask the user for a path should go into the whatever's returned by
> SHGetFolderLocation(.., CSIDL_APPDATA, ..);
>
>
> _____________________________________
> andrew grant | programmer | climax brighton
> ag...@cl... - www.climax.co.uk
>
>
>
>
>
>
> > -----Original Message-----
> > From: Colin Fahey [mailto:cp...@ea...]
> > Sent: 04 December 2003 20:42
> > To: gam...@li...
> > Subject: Re: [GD-General] A portable preferences library
> >
> >
> > 2003 December 4th
> > Thursday
> >
> > I have used the following scheme for storing user preferences
> > for an application:
> >
> > [1] A plain text file in the same directory as the executable,
> >        with the extension *.txt rather than something else (like
> >        *.ini);
> >
> > [2] The application, when launched, can determine the path of its
> >       executable file, and thus the location of the corresponding
> >       user preferences text file;
> >
> > [3] All aspects of reading the user preferences text file are
> >       fault-tolerant; re-ordering, adding, removing fields will
> >       have the least possible effect -- and field values are
> >       similarly checked and clipped to sane limits.
> >
> > Security of the preferences is not an issue for my use of this scheme.
> >
> > Benefits of this scheme:
> >
> >   [a] One can have many independent instances of the application
> >         on a single machine, each with different preferences;
> >
> >   [b] The user can edit preferences if the application malfunctions,
> >         which is impossible in a scheme where the application itself
> >         is the only entity that can manipulate the preferences file;
> >
> >   [c] Users can send or receive preferences files, or disucss
> >         specific named settings, via e-mail or web pages;
> >
> >   [d] Settings in the preferences file can correspond to an
> >         application's scripting system -- so that the preferences
> >         file is nothing more than a batch of scripting commands
> >         that can otherwise be entered at run-time in the
> >         application itself (as in a console window for a video
> >         game);
> >
> >   [e] Settings persist after clean install of operating system;
> >
> >   [f] Application and settings can be stored on a CD-ROM or
> >         portable disk or flash-memory device, and one can
> >         take it to someone else's computer and operate the
> >         application without doing an "installation" or
> >         polluting their computer with any files whatsoever;
> >         (I bring my prototype applications to a friend's house
> >         for demonstration on my keychain USB memory device,
> >         and execute directly from the keychain!)
> >
> > Basically, I'm a strong believer of the settings following
> > the application around.  I think the old MacIntosh operating
> > system hid a kind of directory system behind the application
> > icon -- with the "resource fork" and "data fork", which was a
> > pretty good idea because it allowed data associated with a
> > program to be bound to the program.  Thus, moving or copying
> > the icon would assure that all settings and data moved with
> > it. It was a nice abstraction that simplified the notion of
> > "application" and reduced confusion when moving it around.
> >
> > Maybe I'm hard-core, but I think everything an application
> > needs to operate, short of the absolutely guaranteed
> > resources of the operating system, should be packaged with
> > the application -- and totally portable.  I should be able to
> > run any application on anyone's computer from my keychain
> > memory device, without adding any files to their computer!
> >
> > I think multi-user systems is an antiquated concept.  But if
> > I must support multiple users of a single application (as
> > opposed to each user installing his or her own copy of the
> > application), then individual preferences files can be stored
> > with the application. "preferences_bob.txt",
> > "preferences_joe.txt", etc.  Putting these preferences
> > anywhere else but with the application leads to
> > potential pollution that might never go away.  Lots of
> > irresponsible developers don't do a good job of
> > un-installation -- or somehow the application disappears from
> > the computer without un-install ever happening, leaving tons
> > of scattered junk behind.
> >
> > I always thought the Windows registry was a disaster; it
> > encouraged people to centralize critical information, and it
> > has been a source of confusion and annoyance for users.
> > Protecting the integrity of this single trash heap is silly.
> >
> > Okay, I sympathize with the idea that putting everything in
> > one place somehow seems more organized.  I dislike the idea
> > of things being scattered around.  But I think it's perfectly
> > good to put things in self-contained bundles that do not rely
> > on any centralized thing or on scattered things.  It's very clean.
> >
> > I think rather than pushing itself upon one's computer (like
> > a formal installation procedure), applications should be
> > passive and the
> > operating system should instead scan for applications upon
> > boot-up. Thus, the "Start" menu is populated at boot time and
> > is 100% in sync with available applications.  Applications
> > can contain
> > preferences about placement in the "Start" menu hierarchy,
> > much like an application can propose its own icon.  The key
> > is to eliminate the idea of "installation".
> >
> > Okay, some of these ideas are radical, but I just wanted to
> > share my own thoughts about preferences files.
> >
> > --- Colin
> >
> > cp...@ea...
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us
> > help YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

RE: [GD-General] A portable preferences library

[Crosbie F. <cr...@cy...>]

> From: Andrew Grant
> Also your scheme falls down the minute somebody without write
> access to the
> games folder attempts to play it. Something that's pretty
> common these days
> where Dad has to install the games little Johnny wants to
> play on the family
> PC. I'd be surprised if your approach makes it through QA of
> any publisher worth their salt.

You could compare it with Blizzard's requirement for Warcraft III players to
be administrators (on W2K, etc.).

RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

>> I think multi-user systems is an antiquated concept. 

You're joking right?

Also your scheme falls down the minute somebody without write access to the
games folder attempts to play it. Something that's pretty common these days
where Dad has to install the games little Johnny wants to play on the family
PC. I'd be surprised if your approach makes it through QA of any publisher
worth their salt.

I agree the registry isn't the place to store the data, but neither is the
game install folder. Anything you need to save from your game and that
doesn't ask the user for a path should go into the whatever's returned by
SHGetFolderLocation(.., CSIDL_APPDATA, ..);


_____________________________________
andrew grant | programmer | climax brighton
ag...@cl... - www.climax.co.uk






> -----Original Message-----
> From: Colin Fahey [mailto:cp...@ea...] 
> Sent: 04 December 2003 20:42
> To: gam...@li...
> Subject: Re: [GD-General] A portable preferences library
> 
> 
> 2003 December 4th
> Thursday
> 
> I have used the following scheme for storing user preferences 
> for an application:
> 
> [1] A plain text file in the same directory as the executable,
>        with the extension *.txt rather than something else (like
>        *.ini);
> 
> [2] The application, when launched, can determine the path of its
>       executable file, and thus the location of the corresponding
>       user preferences text file;
> 
> [3] All aspects of reading the user preferences text file are 
>       fault-tolerant; re-ordering, adding, removing fields will
>       have the least possible effect -- and field values are 
>       similarly checked and clipped to sane limits.
> 
> Security of the preferences is not an issue for my use of this scheme.
> 
> Benefits of this scheme:
> 
>   [a] One can have many independent instances of the application
>         on a single machine, each with different preferences;
> 
>   [b] The user can edit preferences if the application malfunctions,
>         which is impossible in a scheme where the application itself
>         is the only entity that can manipulate the preferences file;
> 
>   [c] Users can send or receive preferences files, or disucss
>         specific named settings, via e-mail or web pages;
> 
>   [d] Settings in the preferences file can correspond to an
>         application's scripting system -- so that the preferences
>         file is nothing more than a batch of scripting commands
>         that can otherwise be entered at run-time in the 
>         application itself (as in a console window for a video
>         game);
> 
>   [e] Settings persist after clean install of operating system;
> 
>   [f] Application and settings can be stored on a CD-ROM or
>         portable disk or flash-memory device, and one can 
>         take it to someone else's computer and operate the 
>         application without doing an "installation" or 
>         polluting their computer with any files whatsoever;
>         (I bring my prototype applications to a friend's house
>         for demonstration on my keychain USB memory device,
>         and execute directly from the keychain!)
> 
> Basically, I'm a strong believer of the settings following 
> the application around.  I think the old MacIntosh operating 
> system hid a kind of directory system behind the application 
> icon -- with the "resource fork" and "data fork", which was a 
> pretty good idea because it allowed data associated with a 
> program to be bound to the program.  Thus, moving or copying 
> the icon would assure that all settings and data moved with 
> it. It was a nice abstraction that simplified the notion of 
> "application" and reduced confusion when moving it around.
> 
> Maybe I'm hard-core, but I think everything an application 
> needs to operate, short of the absolutely guaranteed 
> resources of the operating system, should be packaged with 
> the application -- and totally portable.  I should be able to 
> run any application on anyone's computer from my keychain 
> memory device, without adding any files to their computer!
> 
> I think multi-user systems is an antiquated concept.  But if
> I must support multiple users of a single application (as 
> opposed to each user installing his or her own copy of the 
> application), then individual preferences files can be stored 
> with the application. "preferences_bob.txt", 
> "preferences_joe.txt", etc.  Putting these preferences 
> anywhere else but with the application leads to 
> potential pollution that might never go away.  Lots of 
> irresponsible developers don't do a good job of 
> un-installation -- or somehow the application disappears from 
> the computer without un-install ever happening, leaving tons 
> of scattered junk behind.
> 
> I always thought the Windows registry was a disaster; it 
> encouraged people to centralize critical information, and it 
> has been a source of confusion and annoyance for users.  
> Protecting the integrity of this single trash heap is silly.
> 
> Okay, I sympathize with the idea that putting everything in 
> one place somehow seems more organized.  I dislike the idea 
> of things being scattered around.  But I think it's perfectly 
> good to put things in self-contained bundles that do not rely 
> on any centralized thing or on scattered things.  It's very clean.
> 
> I think rather than pushing itself upon one's computer (like 
> a formal installation procedure), applications should be 
> passive and the 
> operating system should instead scan for applications upon 
> boot-up. Thus, the "Start" menu is populated at boot time and 
> is 100% in sync with available applications.  Applications 
> can contain 
> preferences about placement in the "Start" menu hierarchy, 
> much like an application can propose its own icon.  The key 
> is to eliminate the idea of "installation".
> 
> Okay, some of these ideas are radical, but I just wanted to 
> share my own thoughts about preferences files.
> 
> --- Colin
> 
> cp...@ea...
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> Does SourceForge.net help you be more productive?  Does it 
> help you create better code?  SHARE THE LOVE, and help us 
> help YOU!  Click Here: http://sourceforge.net/donate/ 
> _______________________________________________
> Gamedevlists-general mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] A portable preferences library

[Colin F. <cp...@ea...>]

2003 December 4th
Thursday

I have used the following scheme for storing user preferences for
an application:

[1] A plain text file in the same directory as the executable,
       with the extension *.txt rather than something else (like
       *.ini);

[2] The application, when launched, can determine the path of its
      executable file, and thus the location of the corresponding
      user preferences text file;

[3] All aspects of reading the user preferences text file are 
      fault-tolerant; re-ordering, adding, removing fields will
      have the least possible effect -- and field values are 
      similarly checked and clipped to sane limits.

Security of the preferences is not an issue for my use of this
scheme.

Benefits of this scheme:

  [a] One can have many independent instances of the application
        on a single machine, each with different preferences;

  [b] The user can edit preferences if the application malfunctions,
        which is impossible in a scheme where the application itself
        is the only entity that can manipulate the preferences file;

  [c] Users can send or receive preferences files, or disucss
        specific named settings, via e-mail or web pages;

  [d] Settings in the preferences file can correspond to an
        application's scripting system -- so that the preferences
        file is nothing more than a batch of scripting commands
        that can otherwise be entered at run-time in the 
        application itself (as in a console window for a video
        game);

  [e] Settings persist after clean install of operating system;

  [f] Application and settings can be stored on a CD-ROM or
        portable disk or flash-memory device, and one can 
        take it to someone else's computer and operate the 
        application without doing an "installation" or 
        polluting their computer with any files whatsoever;
        (I bring my prototype applications to a friend's house
        for demonstration on my keychain USB memory device,
        and execute directly from the keychain!)

Basically, I'm a strong believer of the settings following the
application around.  I think the old MacIntosh operating system
hid a kind of directory system behind the application icon --
with the "resource fork" and "data fork", which was a pretty
good idea because it allowed data associated with a program to
be bound to the program.  Thus, moving or copying the icon
would assure that all settings and data moved with it.
It was a nice abstraction that simplified the notion of 
"application" and reduced confusion when moving it around.

Maybe I'm hard-core, but I think everything an application needs
to operate, short of the absolutely guaranteed resources of the
operating system, should be packaged with the application --
and totally portable.  I should be able to run any application
on anyone's computer from my keychain memory device, without
adding any files to their computer!

I think multi-user systems is an antiquated concept.  But if
I must support multiple users of a single application (as opposed
to each user installing his or her own copy of the application),
then individual preferences files can be stored with the application.
"preferences_bob.txt", "preferences_joe.txt", etc.  Putting these
preferences anywhere else but with the application leads to 
potential pollution that might never go away.  Lots of irresponsible
developers don't do a good job of un-installation -- or somehow the
application disappears from the computer without un-install ever
happening, leaving tons of scattered junk behind.

I always thought the Windows registry was a disaster; it encouraged
people to centralize critical information, and it has been a source
of confusion and annoyance for users.  Protecting the integrity of
this single trash heap is silly.

Okay, I sympathize with the idea that putting everything in one place
somehow seems more organized.  I dislike the idea of things being
scattered around.  But I think it's perfectly good to put things in
self-contained bundles that do not rely on any centralized thing or
on scattered things.  It's very clean.

I think rather than pushing itself upon one's computer (like a formal
installation procedure), applications should be passive and the 
operating system should instead scan for applications upon boot-up.
Thus, the "Start" menu is populated at boot time and is 100% in
sync with available applications.  Applications can contain 
preferences about placement in the "Start" menu hierarchy, much
like an application can propose its own icon.  The key is to eliminate
the idea of "installation".

Okay, some of these ideas are radical, but I just wanted to share my
own thoughts about preferences files.

--- Colin

cp...@ea...

Re: [GD-General] A portable preferences library

[<ma...@ch...>]

On Wed, 3 Dec 2003, Brian Hook wrote:

> 
> 
> On Wed, 3 Dec 2003 15:53:17 +0100 (CET), ma...@ch... wrote:
> > On Tue, 2 Dec 2003, Brian Hook wrote:
> >
> >
> >> PrefsLib_OpenPrefs( &p, "~/MyCompany/ThisGame" ); //local to user
> >>
> >
> > I hope this maps to  ~/.MyCompany ?
                           ^

Please note the .
              
> 
> Yes, that is the intent, although in retrospect, encoding that in the
> filename is probably not the right way to do things.  I'll probably
> change it to:
> 
> PrefsLib_OpenPrefs( &p, "MyCompany/ThisGame", PLFLAG_SYSTEM );
> 
> where you can specify PLFLAG_SYSTEM, PLFLAG_USER or
> PLFLAG_CURRENT_DIR.

Sounds better!

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
Maybe you don't care about Microsoft's victims. When Microsoft starts
charging you for every time you turn your computer on, will you care then?
                                        - Melantha Bacchae on /.

Re: [GD-General] A portable preferences library

[Pablo <pe...@te...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=46rom: Brian Hook <ho...@py...>
> Preference objects can be opened either system-wide (corresponding to
> HKEY_LOCAL_MACHINE on Windows, "/Library" on OS X, "/usr/local/share"
> on Linux) or locally (corresponding to HKEY_CURRENT_USER on Windows,
> "~/Library" on OS X, and "~" on Linux).

	I wonder if /var/lib isn't a better place to store such a data, since many=
=20
people mount their /usr filesystems in read-only mode.
	A clear example for this can be seen in the Mozilla package for Debian. Th=
e=20
original version of Mozilla stores everything in /usr/local/mozilla, while=
=20
the Debian package puts global configuration files in /var/lib/mozilla and=
=20
creates the appropiate symlinks so the application can find its files.

	Greetings.
=2D --=20
Pablo Brasero
http://www.pablobm.com
mailto:pab...@hi...
jabber:otn...@ja...
Usuario registrado de Linux n=FAmero 286.361
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/zna5J8SVBd7KWfwRAhD+AKDFjnbaru6Lj/zP1Qhco7IufOFEtQCdHAoH
ikAeE+HbcuAbZoPW+yCWZTs=3D
=3DVaKt
=2D----END PGP SIGNATURE-----

Re: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

On Wed, 3 Dec 2003 15:53:17 +0100 (CET), ma...@ch... wrote:
> On Tue, 2 Dec 2003, Brian Hook wrote:
>
>
>> PrefsLib_OpenPrefs( &p, "~/MyCompany/ThisGame" ); //local to user
>>
>
> I hope this maps to  ~/.MyCompany ?

Yes, that is the intent, although in retrospect, encoding that in the 
filename is probably not the right way to do things.  I'll probably 
change it to:

PrefsLib_OpenPrefs( &p, "MyCompany/ThisGame", PLFLAG_SYSTEM );

where you can specify PLFLAG_SYSTEM, PLFLAG_USER or 
PLFLAG_CURRENT_DIR.

Brian

Re: [GD-General] Registry/CFP/Files (WAS: A portable preferences library)

[Brian H. <ho...@py...>]

> I'm curious why you would want to use the Windows Registry or MacOS
> CFPrefs when you could just use the file system on all platforms?

That's a good question, and in general I agree with you that having a 
separate configuration file seems to make a lot more sense.

But for better or for worse, the registry has some advantages.  It 
transparently handles multiple users without actually having to query 
the user's home path; it is a standard practice; there is little 
opportunity for the user to accidentally muck with it (file system 
errors occur a lot more than registry errors); and usually the changes 
are isolated to an area only your application cares about.

Also, it's a standardized location.  Right now a lot of applications 
are dumping settings in /windows/system32 or /windows or /Program 
Files/Application or /Documents and Settings/user, etc.

I abhor applications that litter system areas with their own special 
files.

> Might you at least make a file-system-only
> implementation option on each platform?

Definitely.  I would like to do a file-system fallback path that can 
be specified, but this does add more work but hopefully could be 
generalized and shared among all implementations.

Brian

[GD-General] Registry/CFP/Files (WAS: A portable preferences library)

[Garett B. <gt...@st...>]

// Everyone seems like they have to write their own
// portable preferences/registry wrapper...
// It is designed to be minimal, and will wrap around
// the Windows registry; CFPreferences on MacOS/OS X;
// and the standard file system on Linux.


Brian and others,

	I'm curious why you would want to use the Windows Registry or MacOS CFPrefs
when you could just use the file system on all platforms?  What is the
advantage of using the Operating System's configuration database?  Might you
at least make a file-system-only implementation option on each platform?

	Before Win2K/XP, I considered registry-based configuration a huge
disadvantage, since it was exceptionally difficult to persist settings if
you needed to reinstall the OS.  It was always nice to find that many non-MS
apps still used .ini-file-esque settings and would just automagically work
after a reinstall.

Regards,
Garett Bass
gt...@st...

Re: [GD-General] A portable preferences library

[<ma...@ch...>]

On Tue, 2 Dec 2003, Brian Hook wrote:

> PrefsLib_OpenPrefs( &p, "~/MyCompany/ThisGame" ); //local to user

I hope this maps to  ~/.MyCompany ?

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
Unix is user-friendly; it's just a little particular about which users it is
friendly to.

Re: [GD-General] A portable preferences library

[J C L. <cl...@ka...>]

On Tue, 2 Dec 2003 12:05:59 -0500 
Brian Hook <ho...@py...> wrote:
> On Tue, 02 Dec 2003 11:42:59 -0500, J C Lawrence wrote:

>> I did a little STL-based thang which reads and writes a map of
>> "<StanzaName>:Token" -> <value> to and from a text file where the
>> value is a multi-value which transparently handles strings, floating
>> point, integers etc in the same type.  Very nice, simple, and easy to
>> use. Load populates the map and everything else is an STL map
>> reference.

> Except it uses STL =3D)

True, except that it would be easy enough to move to any of the
associative array implementations.  There's nothing marrying it to STL.

> I'm using ANSI C since it is, by far, the most plug-and-play language
> for cross-platform work.

I also greatly prefer C, but that was not the political choice at that
time.  Were I do go the C route I'd likely end up with something very
similar but based on *dbm and one of the varray implementations.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

On Tue, 02 Dec 2003 11:42:59 -0500, J C Lawrence wrote:
> On Tue, 2 Dec 2003 01:59:30 -0500
> I did a little STL-based thang which reads and writes a map of
> "<StanzaName>:Token" -> <value> to and from a text file where the
> value is a multi-value which transparently handles strings,
> floating point, integers etc in the same type.  Very nice, simple,
> and easy to use. Load populates the map and everything else is an
> STL map reference.

Except it uses STL =3D)

(M-x skip-C++-and-STL-argument-mode)

I'm using ANSI C since it is, by far, the most plug-and-play language 
for cross-platform work.

Brian

Re: [GD-General] A portable preferences library

[J C L. <cl...@ka...>]

On Tue, 2 Dec 2003 01:59:30 -0500 
Brian Hook <ho...@py...> wrote:

> Everyone seems like they have to write their own portable
> preferences/registry wrapper.  I've got one that I hacked up, and I'm
> currently in the process of refactoring it and will make it open
> source.

I did a little STL-based thang which reads and writes a map of
"<StanzaName>:Token" -> <value> to and from a text file where the value
is a multi-value which transparently handles strings, floating point,
integers etc in the same type.  Very nice, simple, and easy to use.
Load populates the map and everything else is an STL map reference.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

[GD-General] A portable preferences library

[Brian H. <ho...@py...>]

Everyone seems like they have to write their own portable 
preferences/registry wrapper.  I've got one that I hacked up, and I'm 
currently in the process of refactoring it and will make it open 
source.

It is designed to be minimal, and will wrap around the Windows 
registry; CFPreferences on MacOS/OS X; and the standard file system on 
Linux.

The features will be:

- open/close/delete a preferences object

- read/write 16-bit, 32-bit, 64-bit, float, double, string, and 
byte-bucket objects safely (e.g. endianess)

- delete keys

Preference objects can be opened either system-wide (corresponding to 
HKEY_LOCAL_MACHINE on Windows, "/Library" on OS X, "/usr/local/share" 
on Linux) or locally (corresponding to HKEY_CURRENT_USER on Windows, 
"~/Library" on OS X, and "~" on Linux).

If you do not have privilege for the operation, tough cookies -- it's 
the app's responsibility to ensure that appropriate privilege exists.

Key enumeration is not planned at this time.

As an example, using an ad hoc API, it would look something like:

prefs p;

PrefsLib_OpenPrefs( &p, "~/MyCompany/ThisGame" ); //local to user
PrefsLib_WriteFloat( p, "joystickX", fJoystick );
PrefsLib_WriteString( p, "username", getUserName() );
PrefsLib_ClosePrefs( p );

You get the gist.

If anyone has comments/suggestions, I'd love to hear them.

Brian

Re: [GD-General] variadic functions

[Thatcher U. <tu...@tu...>]

On Nov 27, 2003 at 10:22 +0800, Brett Bibby wrote:
> 
> I'm trying to bind our scripting engine to our game engine and having
> trouble with variadic functions

I'm surprised that you have variadic functions on the C/C++ side of
your engine.  What are they used for?

Anyway, one possible approach is to do the wrapping in reverse.
I.e. rewrite those functions avoiding the C/C++ implementation of
variadic parameters, and instead use your scripting language's
parameter-passing mechanism.  Bind the functions directly to your
scripting language.  Provide wrappers for calling them from C/C++.

E.g. let's say you're using Lua, and you have an add() function that
takes an arbitrary number of doubles and returns their sum:

double add(int arg_count, ...) { /* ... */ }

You can implement that using the va_ macros, but instead of doing
that, you could implement it using the Lua API:

int add_lua(lua_State* L)
{
	int arg_count = (int) luaL_checknumber(1);
	double sum = 0;
	for (int i = 0; i < arg_count; i++)
	{
		sum += luaL_checknumber(2 + i);
	}
	lua_pushnumber(L, sum);
	return 1;
}

// Wrapper for calling from C++.
double add(int arg_count, ...)
{
	// Seat of the pants code, probably incorrect!
	lua_pushnumber(L, arg_count);
	va_list argp;
	va_start(argp, arg_count);
	for (int i = 0; i < arg_count; i++)
	{
		lua_pushnumber(L, va_arg(argp, double));
	}
	va_end(argp)
	add_lua(L);
	double result = luaL_tonumber(L, -1);
	lua_pop(arg_count + 2);
	return result;
}
// etc.

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] variadic functions

[Andras B. <bn...@ma...>]

Brett,

What do you mean by using a generalized solution? In the case of a
vararg function, you have to describe the parameters somehow! And the
easiest way to do it is via a string: for example "iicfds" would mean:
(int, int, char, float, double, char*).

Of course this means that you have to prepare your function to be able
to interpret this format string, and act appropriately, but I think
this should not be a problem as there is no point in writing a vararg
function that can't handle different sets of parameters...

In case you only have a couple of variants, then it might be more
efficient to make different versions of the function to handle each
case, and bind them separately.

And to answer your last question: Yes, simply pushing the values and
calling the func should do the job. But don't forget to pop the values
from the stack after the func returned, as it's your (the caller's)
job to clean-up the stack!!!

Cheers,


Andras

Thursday, November 27, 2003, 11:02:46 AM, Brett Bibby wrote:

> Andras,
> Thanks for the post.  Pretty much my conclusion too.  But I'm not using
> this for printf so I need a generalized solution, although I could
> theoretically create bindings for every possible case (which is normal
> for scripting engine binding anyway).  Since the callee doesn't know how
> many parameters there are, it seems I just need to push the values to
> the stack in assembly code and then call the variadic function.  Does
> that sound right?
> Brett

RE: [GD-General] variadic functions

[Stefan B. <ste...@di...>]

   No matter how you do it, it's going to be very architecture dependent so
don't worry about portability. There is no portable way using C++. You might
want to take a peek at libffi, which is a library which implements function
calling for various platforms. I think the latest version is 2.0 but I don't
have a link handy. You will probably find it at the Portable.Net site
(probably in the core runtime):

  http://www.southern-storm.com.au/portable_net.html

   Last time I checked that had a more recent version than what could be
found on the official libffi site.

Cheers,
Stef! :)

Stefan Boberg
Chief Technical Officer
Digital Illusions CE AB

-----Original Message-----
From: Brett Bibby [mailto:res...@ga...] 
Sent: den 27 november 2003 11:03
To: gam...@li...
Subject: Re: [GD-General] variadic functions

Andras,
Thanks for the post.  Pretty much my conclusion too.  But I'm not using
this for printf so I need a generalized solution, although I could
theoretically create bindings for every possible case (which is normal
for scripting engine binding anyway).  Since the callee doesn't know how
many parameters there are, it seems I just need to push the values to
the stack in assembly code and then call the variadic function.  Does
that sound right?
Brett

----- Original Message ----- 
From: "Andras Balogh" <bn...@ma...>
To: <gam...@li...>
Sent: Thursday, November 27, 2003 4:28 PM
Subject: Re: [GD-General] variadic functions


> Hi Brett,
>
> > The compiler strips the "..." off the back and makes a normal
function
> > out of the variadic one, and the preceeding four functions are then
used
> > to access these unknown parameters.  The start function takes the
last
> > known parameter as a value so at first glance it seems the function
> > knows how many paramters there are because because it can compare
the
> > last known argument with the value on the stack.  The problem is
that
> > since the parameters were pushed in reverse order how would it know
how
> > many parameters there are?  If it were in direct order, you could
take
> > the stack pointer minus the stack pointer at the last parameter
position
> > (which is provided) and the diffference would be the number of
> > arguments.  But since they are reversed how does the va_arg function
> > know when to stop?
>
> The answer is simple: It does not know! :(
>
> That's exactly why vararg functions always use the cdecl calling
> convention. This requires that the caller cleans the stack, because
> the caller always knows the number of params on the stack, while the
> calle doesn't (in the case of vararg).
>
> Think of printf! The first param is supposed to be a pointer to a
> format string. Reading that string printf determines how many (and of
> what type) values it has to read from the stack. I'm pretty sure that
> every one of us crashes a program every once in a while because of
> unmatching params and format string. The reason for this is that there
> is just no way printf can verify the stuff you gave is valid.
>
> > Has anybody else run into this before?  How did you solve it?
>
> Well, you could use a format string like printf, or something similar.
>
> If you do this for scripting, then your script binding engine knows
> all the params, so it might be a good idea to generate the format
> description string automatically. This way the script writers could
> call the function with any number of params without explicitly
> describing their type and number in a format string.
>
> The ultimate solution would be of course the introduction of a new
> calling convention, but I don't really know who's responsibility is
> this... anyone? :)
>
>
> Andras
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557

Re: [GD-General] variadic functions

[Brett B. <res...@ga...>]

Andras,
Thanks for the post.  Pretty much my conclusion too.  But I'm not using
this for printf so I need a generalized solution, although I could
theoretically create bindings for every possible case (which is normal
for scripting engine binding anyway).  Since the callee doesn't know how
many parameters there are, it seems I just need to push the values to
the stack in assembly code and then call the variadic function.  Does
that sound right?
Brett

----- Original Message ----- 
From: "Andras Balogh" <bn...@ma...>
To: <gam...@li...>
Sent: Thursday, November 27, 2003 4:28 PM
Subject: Re: [GD-General] variadic functions


> Hi Brett,
>
> > The compiler strips the "..." off the back and makes a normal
function
> > out of the variadic one, and the preceeding four functions are then
used
> > to access these unknown parameters.  The start function takes the
last
> > known parameter as a value so at first glance it seems the function
> > knows how many paramters there are because because it can compare
the
> > last known argument with the value on the stack.  The problem is
that
> > since the parameters were pushed in reverse order how would it know
how
> > many parameters there are?  If it were in direct order, you could
take
> > the stack pointer minus the stack pointer at the last parameter
position
> > (which is provided) and the diffference would be the number of
> > arguments.  But since they are reversed how does the va_arg function
> > know when to stop?
>
> The answer is simple: It does not know! :(
>
> That's exactly why vararg functions always use the cdecl calling
> convention. This requires that the caller cleans the stack, because
> the caller always knows the number of params on the stack, while the
> calle doesn't (in the case of vararg).
>
> Think of printf! The first param is supposed to be a pointer to a
> format string. Reading that string printf determines how many (and of
> what type) values it has to read from the stack. I'm pretty sure that
> every one of us crashes a program every once in a while because of
> unmatching params and format string. The reason for this is that there
> is just no way printf can verify the stuff you gave is valid.
>
> > Has anybody else run into this before?  How did you solve it?
>
> Well, you could use a format string like printf, or something similar.
>
> If you do this for scripting, then your script binding engine knows
> all the params, so it might be a good idea to generate the format
> description string automatically. This way the script writers could
> call the function with any number of params without explicitly
> describing their type and number in a format string.
>
> The ultimate solution would be of course the introduction of a new
> calling convention, but I don't really know who's responsibility is
> this... anyone? :)
>
>
> Andras
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557

Re: [GD-General] variadic functions

[Andras B. <bn...@ma...>]

Hi Brett,

> The compiler strips the "..." off the back and makes a normal function
> out of the variadic one, and the preceeding four functions are then used
> to access these unknown parameters.  The start function takes the last
> known parameter as a value so at first glance it seems the function
> knows how many paramters there are because because it can compare the
> last known argument with the value on the stack.  The problem is that
> since the parameters were pushed in reverse order how would it know how
> many parameters there are?  If it were in direct order, you could take
> the stack pointer minus the stack pointer at the last parameter position
> (which is provided) and the diffference would be the number of
> arguments.  But since they are reversed how does the va_arg function
> know when to stop?

The answer is simple: It does not know! :(

That's exactly why vararg functions always use the cdecl calling
convention. This requires that the caller cleans the stack, because
the caller always knows the number of params on the stack, while the
calle doesn't (in the case of vararg).

Think of printf! The first param is supposed to be a pointer to a
format string. Reading that string printf determines how many (and of
what type) values it has to read from the stack. I'm pretty sure that
every one of us crashes a program every once in a while because of
unmatching params and format string. The reason for this is that there
is just no way printf can verify the stuff you gave is valid.

> Has anybody else run into this before?  How did you solve it?

Well, you could use a format string like printf, or something similar.

If you do this for scripting, then your script binding engine knows
all the params, so it might be a good idea to generate the format
description string automatically. This way the script writers could
call the function with any number of params without explicitly
describing their type and number in a format string.

The ultimate solution would be of course the introduction of a new
calling convention, but I don't really know who's responsibility is
this... anyone? :)


Andras