gamedevlists-general — List for discussing general game development issues

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

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

> You need to make your mind up on whether you think prefs files are
> movable across architecture or not? 

Oh, they definitely are.  Sharing prefs is something I would hate to 
rule out.

> If they are, then float-format
> will kill you, as will endianness in integers.

IEEE-754 floats are pretty standard, and my lib handles all the 
endianess stuff just fine.  Of course, for raw binary export, it's up 
to the application to make sure that it does the right thing if 
serializing structs (which it shouldn't be doing, but hey, I can't 
control the app).

> Personally, I think that floating point *prefs* are going to be
> pretty damn weird to start with, and you need to keep in mind that
> that information is entered either as text (ie, in an EDIT
> control), or by tweaking a scrollbar. In either case, the user
> can't really complain about that last bit that might go wrong in
> the ASCII->FLOAT conversion.

Agreed, that just happened to be the first example I could think of.

> I'm surprised that no-one has said "use XML format please" - its
> not that painful, given that you'll have a fairly limited schema to
> implement.

Sure, it's not that bad, but it's also a lot of overhead for not much 
in return.

Nothing beats Windows-style INI files for parsing simplicity goodness. 
=3D)

Brian

[GD-General] Windows vs... (WAS: A portable preferences library)

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

// Jeff Laing wrote:
//
// I'm envisioning that instead of having a readily
// visible Quake.app icon, I have Jeffs Quake and
// Paulines Quake icons - double-clicking those load
// up Quake.app and pre-load my, or her, preferences
// and thus open the correct save games, mouse
// settings, etc.

You can already do this with Quake:

	1. make a shortcut to quake.exe
	2. edit the shortcut properties
	3. add -exec Jeff.cfg to the "Target:" command line
	4. click OK
	5. rename the shortcut "Jeff's Quake"
	6. rinse and repeat for Pauline.cfg

Regards,
Garett

[GD-General] RE: A portable preferences library

[Jeff L. <je...@SP...>]

> I agree with Brian; I want to be able to delete an application 
> directory (or perhaps one day it will be an archive object) and 
> have it gone -- without the operating system being involved in 
> anything other than a file deletion operation.

whereas I want to be able to delete the application (the hundreds of MB) but
keep my save games and keystroke preferences so that in six months time when
I load the game back (as I did recently with Quake), its all still there.

You are *not* going to keep everyone happy in this space.

> On the subject of multiple instances of an application versus the
> ability to double-click to open documents...  Okay, this feature
> would require a list of file extensions and paths to associated
> applications, which I assume is currently found in the Registry.
> [snip]
> Microsoft may have used something called a Registry file for 
> this purpose

I have to admit, this sounded spookily like you don't know how Windows works
at all, which sort of skews the value of some of the opinions being offered.

(End of unintended offense)

> As far as I'm concerned, this is not compromising my philosophy.
> The window system is an application with its own "preferences",
> such as what application to use to open a given file extension.

Actually, its the Explorer or more correctly the "Windows Shell" that has
this preference, but other applications can and do look into that space, a
big advantage to having a semi-wellknown globally readable repository/format
for your preferences.

(Again, in our non-game application we do exactly this - sometimes we need
to mess with another app, and we don't really want to know where its been
installed, we just ask Windows "who would open this document type if we
double-clicked on it" and it gives us back the full pathname to the
appropriate app.  We don't launch it, we just exploit the fact that we found
it without having to deal with searching file systems for filenames that are
different depending on native language, etc)

> Microsoft may have used something called a Registry file for 
> this purpose -- but I don't see why all other applications on 
> the computer should be considered subordinate (in the sense of
> "being part of") to the Microsoft window system application.

Not subordinate.  Consistent with.  Consistency is a good thing when you are
trying to work out whats gone wrong with someone elses app.  If they do the
same thing as everyone else, they are a lot easier to debug.

> 	Somehow I doubt there are many fathers who are running serious
system-level
> multi-user setups at home.  More likely everyone just uses the same login
> and shares the same clutter.  Sure, it's still multi-user, as in "used by
> multiple people", but not at the registry level.

Hmmm, I'd invite you to my place, or my brothers, but we're probably a bit
far away.

I definitely have multi-user setups which are intended precisely to stop the
5 year olds from messing stuff up.  In my brothers case, its our mother the
65 year old that he protects the system from.

Now, we happen to be the computer literate ones in the family - there is
absolutely no reason why you can't swap father/child in any of this
discussion, as is the case with my brother.  He does the admin, and the
parents use a "nice safe, difficult to break" system.

> In fact, I bet that going forward that higher security privileges and 
> multiuser configurations will become more important.  One of the most 
> common sources of spyware/virii are random things that kids download 
> off the internet -- I'm amazed how many people will "click here" just 
> because something says "CLICK HERE!" 

Ask a security zealot what they think of MacOSX these days - just about
anything downloaded from the net says "ok, authorise me as root" without
giving users a clue about what they are actually allowing.

> Originally I was thinking it would be a binary file format, strictly 
> because I wanted the ability to serialize raw binary data "just in 
> case".  Now you could make a valid argument that you could always 
> convert to text, i.e. 3.14 becomes "3.14", but maybe you don't want to 
> suffer a data conversion loss or something, I dunno.
> 
> Point being that I'd rather not dictate policy if I don't have to.

You need to make your mind up on whether you think prefs files are movable
across architecture or not?  If they are, then float-format will kill you,
as will endianness in integers.

Personally, I think that floating point *prefs* are going to be pretty damn
weird to start with, and you need to keep in mind that that information is
entered either as text (ie, in an EDIT control), or by tweaking a scrollbar.
In either case, the user can't really complain about that last bit that
might go wrong in the ASCII->FLOAT conversion.

I'm surprised that no-one has said "use XML format please" - its not that
painful, given that you'll have a fairly limited schema to implement.

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

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

On Thu, 4 Dec 2003 16:49:45 -0800 
Colin Fahey <cp...@ea...> wrote:

> All user preferences and patched files can be placed or retrieved from
> the application archive by a login (decryption key), but a hacker
> cannot cause any predictable change to the application or its data.

You may like to do some reading up on capability models and the use of
capability models in security.

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

Okay, so back to the actual file format....

Originally I was thinking it would be a binary file format, strictly 
because I wanted the ability to serialize raw binary data "just in 
case".  Now you could make a valid argument that you could always 
convert to text, i.e. 3.14 becomes "3.14", but maybe you don't want to 
suffer a data conversion loss or something, I dunno.

Point being that I'd rather not dictate policy if I don't have to.

So instead of doing a UUEncode, I could do an inefficient translation 
to ASCII by simply converting directly to ASCII.  It would double in 
size if I used hex, but it would still be editable in a text editor.

So if you need to write out 0x12 0x9A 0xBC 0x55 to the key "foo" then 
the file foo.pref would have:

foo=3D129ABC55

Not efficient, but it works.

Any obvious problems going this route?

Brian

RE: [GD-General] A portable preferences library

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

> So, I'm guessing that the multi-user advantages of the registry-
> stored preferences are likely used only by an elite few with some
> serious IT skills.

this is true, but it's still there.  Even if it's just 1% of users, if 
your game sells 200K units, that's 2000 users that will run into 
problems with your game.  

That gets amplified pretty seriously.  Even our own piddly little 
puzzle games ran into this.  

In fact, I bet that going forward that higher security privileges and 
multiuser configurations will become more important.  One of the most 
common sources of spyware/virii are random things that kids download 
off the internet -- I'm amazed how many people will "click here" just 
because something says "CLICK HERE!" 

Brian

Re: [email] [GD-General] RE: Gamedevlists-general digest, Vol 1 #284 - 10 msgs

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

> > Only if he's an admin(which is the root of so many problems..), and if
he
> > is, he can screw up many more things.
>
> If he can't write to that directory, he can't write a preference file into
> it.
> If he can, he can erase its contents.  As I recall.
> Windows != Unix, there is no "chmod a+t" here.
Right, I have been going with the view that the preferences can't be in the
same directory because of that exact reason.

>
> > > you like, but understand that its your config.
> > That's a fun idea, there. For the adventurous type, you could use the
hash
> > that email uses for binary attachments and shove it all into a human
> > readable xml file. Could get big, though...(MD5, I think?).
> > Might be fun to try out in someone's small puzzle type game. oo, oo...
if
> you
> > wanted real fun you could Zip the xml, so humans who wanted to read it
> > would just WinZip it and life would be good. Hmmmm..
>
> I'm not quite sure what you are getting at here.  I'm envisioning that
> instead of having a readily visible Quake.app icon, I have Jeffs Quake and
> Paulines Quake icons - double-clicking those load up Quake.app and
pre-load
> my, or her, preferences and thus open the correct save games, mouse
> settings, etc.
>
> The application would install, by default, a "New User" icon which you can
> either double-click (and it magically detects that you are requesting that
a
> new set of user prefs be created), or perhaps you just duplicate it and
> rename it.
That's what I was getting at. The icon itself holds the preferences and you
use file associations so your program opens with them, and unzips them, and
parses the xml, etc. I was just going off on the ability to shove
*everything* into the one file and still have it human readable.

> > > The truly innovative could, however, write a tiny app that functioned
as
> a
> > > LAUNCHER, that stored the preferences back into itself as resources,
and
> > > passed values on perhaps through environment variables, a command-line
> > > option or a temporary file.
> > That'd be a fun SourceForge project I bet.
>
> To my eye, it'd be a few days work to do the whole thing, given that the
> launcher only has to:
>
> a) load and run another application
>
> Since the registry probably has your install directory anyway, its a
> registry read, and a ShellExecute()
>
> b) act as a REPOSITORY for preferences
>
> You'd probably do this by having the launcher app have a few documented
> entry points that could be accessed via LoadLibrary().
Ah, I was thnking of a more transparent solution, which would be more
difficult to implement, I'd say. Yours is probably better.

-Dan

RE: [GD-General] A portable preferences library

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

// Andrew grant wrote in response to Colin Fahey:
//
// I'd be surprised if your approach makes it through
// QA of any publisher worth their salt.

	Colin's approach is exactly what is used by Quake, Quake2, Quake3,
Half-Life, and by the transitive property, Counter-Strike.  Another popular
game using this technique is Battlefield 1942.

	Personally, I find Colin's suggestion to be a perfectly acceptable means of
managing preferences for a game.  I particularly like the ability to keep a
variety of preference files onhand.  More than one per user can be handy if
you are experimenting with some scripted input behavior in your spare time
but don't want to lose your competition config.

	Now, I'm not sure this is true, but I've heard that Counter-Strike is
currently the most popular online FPS, and that 1942 is second most popular.
And yet you exclude Activision and EA from your set of all "publishers worth
their salt".

// Something that's pretty common these days where
// Dad has to install the games little Johnny wants
// to play on the family PC.

	Ok, this makes me feel a little dumb.  I've been trying to set up a
restricted access user on a Win2k box at work, and no matter what I
disallow, I still can't figure out how to prevent the user from installing
stupid crap from the internet.

	Somehow I doubt there are many fathers who are running serious system-level
multi-user setups at home.  More likely everyone just uses the same login
and shares the same clutter.  Sure, it's still multi-user, as in "used by
multiple people", but not at the registry level.

	So, I'm guessing that the multi-user advantages of the registry-stored
preferences are likely used only by an elite few with some serious IT
skills.  Another example of 99% in, 1% out.  I'm partial to 1942's handy
built-in multiple profiles dialog.  I suppose you could always use a single
registry key to set a default profile for each system-level user.

	Apologies in advance for the rants.

Curious,
Garett

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

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

2003 December 4th
Thursday

> One of which is c:\program files...

Well, this is an example of "build it and they will come".
Microsoft set up an architecture (Registry and protected
directories) to encourage developers to put files in certain
places.  "Program Files", "My Documents", "My Music", 
"My [...]", etc... (Definitely a product of the "Me" 
generation!)  I don't buy in to it.

But keep reading...

> Of course you could install things to c:\unprotectedCrap but that rather
> misses the point of being able to let your kid brother play with the PC and
> be safe in the knowledge he isn't likely to fuck things up.

I admit that under the current version of Windows and Linux,
there might not be a cool way to prevent one's kid brother
or some malicious hacker from messing with the contents of
unprotected directories.

Basically, I think the operating system should protect all
directories and files independently -- and not by mere flags,
but by virtue of the encryption of the entities themselves.
So, the operating system can only control read and write 
access, not the security of the contents.  Compromising the
operating system only compromises the read and write access
to the disk drive, not any user data.

Given the current operation of Windows and Linux, I guess
one must decide what to do based on the "kid brother" scenario.

But consider this:  Even my USB memory device has its own 
password protection, independent of Windows.  I could go
further and encrypt each file stored on my keychain.
Why rely on Windows to enforce the security of drives?
How often have people been horrified to learn that their
disk drives have been "shared" over WiFi or cable modem?

I don't know how one could execute an application from an
encrypted ZIP archive, but if this problem were solved then
the only thing left to worry about is the archive being totally
deleted (something kid brother might do) or being randomly
corrupted, NOT HACKED, by someone with malicious intent.
All user preferences and patched files can be placed or
retrieved from the application archive by a login (decryption
key), but a hacker cannot cause any predictable change to 
the application or its data.

> A lot of people use the auto update functions provided by games, a lot of
> peple don't. I tend to be in the latter as I'd rather download such things
> at work in the background and bung them on a CD instead of sitting at home
> waiting for a game to update itself.

"Real Audio Player", "Macromedia Flash", many games, etc, detect 
their own updates.  Some games, like "Planetside", force the user to
wait for patches to download and take effect upon each login, as
necessary, because its a multiplayer game that requires everyone to
have the same client.  Frankly I dislike how frequently some 
applications are updated or are marked as obsolete.  In the case of
Real Networks products, I suspect the "update" is just a new bundle
of sponsored advertisements and links, and a new opportunity to 
change the End-User License Agreement to introduce a new level of
spying on the user.

I don't like my software depending on outside entities, and I guess
that's the fundamental philosophy behind my ideas.  I don't like 
chasing Microsoft's idea about how people should do things.  I don't
like applications that call home or need to do things with remote
servers to continue operating (unless that is the core purpose of
the application, like a web browser or a multiplayer game).  I don't
like application resources scattered around, or depending on outside
systems to protect the integrity of my own data.

On the subject of saved games or saved preferences...  I think putting
saved games in the application directory is a pretty easy convention
to follow for developers, and easy for end-users to absorb.  I think
the saved game directory should be easy to copy to an alternative 
location, or even merge contents with another saved-game directory
-- so a friend could send you a saved game that you simply copy to 
your own saved-game directory.

I agree with Brian; I want to be able to delete an application 
directory (or perhaps one day it will be an archive object) and 
have it gone -- without the operating system being involved in 
anything other than a file deletion operation.

On the subject of multiple instances of an application versus the
ability to double-click to open documents...  Okay, this feature
would require a list of file extensions and paths to associated
applications, which I assume is currently found in the Registry.
As it is now, one can double-click on a document that is not 
currently associated with an application and then browse for the
application -- or, one can right-click and choose a new application,
potentially with the same exact name (but different path) to 
open the file (or even change the application association for
future double-clicks of the file type).

As far as I'm concerned, this is not compromising my philosophy.
The window system is an application with its own "preferences",
such as what application to use to open a given file extension.
Microsoft may have used something called a Registry file for 
this purpose -- but I don't see why all other applications on 
the computer should be considered subordinate (in the sense of
"being part of") to the Microsoft window system application.
Application-specific data belongs with the application, not
with the window manager application.

In this age of removable media (USB memory devices, etc) and
other ways of transporting computing contexts from machine to 
machine, I don't want any machine to know anything about me.
Also, I don't want to depend on any machine for security.
I visited MIT's campus last month, and I thought it was really
cool that they had Linux terminals all over campus set up in
public spaces like ATM machines.  Of course it was Linux 
running locally and accessing some centralized network drive
for user preferences, but I envision being able to take 
preferences with you and use a terminal totally anonymously
and without any persisting data associated with you.
I think my little keychain "drive" is just the beginning of
the decentralization of information and security.

--- Colin

cp...@ea...

Re: [GD-General] A portable preferences library

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

> Are you thinking the preferences library will be portable enough to
> work for consoles too?

No reason for it not to.  

The general architecture is that you open and close prefs, and when 
you open you can specify if you want them user-level, system-level, 
and whether you prefer a filesystem implementation instead of a 
"native" (Win32 registry and OS X Preferences) implementation.

Obviously, I'm not going to write a PS2 or GC implementation, but the 
API is so simple that layering it should be trivial.

You query a value using an API like PrefLib_GetFloat( "name", &f ), 
etc.  These then dispatch into a portable thunker that converts to a 
canonical little-endian format, and then call the system dependent 
PrefLib_WriteBinary() implementation.

My Win32 implementation is complete, and I'm about 50% complete with 
the filesystem implementation which, in theory, should just work on 
Linux.

To make this manageable, I'm not going to support things like nested 
keys or arbitrarily large data chunks (i.e. movie files, screenshots) 
although I won't prevent people from doing the latter.

> Also, I assume most people don't read/write preferences often, but
> I was wondering if your library would have the concept of loading
> all the prefs in the beginning, then reading/writing them in
> memory, then finally flushing them back to non-volatile storage
> when done?  The reason for this is that memory cards have a limited
> lifespan and are slow to access anyway, so being able to read/write
> to storage only once is a good thing.

Interesting that you should bring this up, because I had to deal with 
this last night.

There's a bit more bookkeeping to doing a purely in-memory system, but 
there are also a couple ugly pitfalls:

1.  Multiple processes accessing the same pref file can clobber each 
other.

2.  The need to flush periodically so that if the app terminates 
unexpectedly, any preferences are not lost due to the crash.

For these reasons, the file system implementation I'm doing is 
actually slow but safe.  Every access forces a file read/parse, modify 
in place, and then a write back out.  Yes, in theory that's amazingly 
slow, but I expect that A.) it won't be that big a problem since 
developers rarely thrash preferences and b.) if it is a problem, I 
expect that developers will end up caching values in memory anyway.

All that said, a memory card implementation could easily cache all the 
data behind the scenes and only flush when PrefLib_ClosePrefs() is 
called.

Brian

[GD-General] RE: Gamedevlists-general digest, Vol 1 #284 - 10 msgs

[Jeff L. <je...@SP...>]

> > Because when push comes to shove, Windows is *still* just DOS - it still
> > requires a PATH environment variable of ";" seperated directory names to
> > search - in fact, with the latest versions of Windows, Microsoft is
> > disparaging the idea of putting your DLL's into the system 
> directory, but they don't give adequate documentation or support of the 
> API's required to insert directories into the search path.

> Hmm.. Sooo.. you can't do something like LoadLibrary(MyExeLocation +
> \\MyLibrary.dll); ??

This only works if you softlink to everything, and doesn't if the DLL you
are loading hard-links to something not visible in the path.  Been there,
done that.  My application (not technically a game) does lots of chdir()
operations while dynamically loading DLL's to ensure that the current
directory is optimal for softlinking support.

Sure, you can set your APP up this way, but in general terms, it pushs up
the error rate enormously since you can't tell that you have your
application built correctly till RUNTIME when you discover all the missing
entry points.

> Only if he's an admin(which is the root of so many problems..), and if he
> is, he can screw up many more things.

If he can't write to that directory, he can't write a preference file into
it.
If he can, he can erase its contents.  As I recall.
Windows != Unix, there is no "chmod a+t" here.

> > you like, but understand that its your config.
> That's a fun idea, there. For the adventurous type, you could use the hash
> that email uses for binary attachments and shove it all into a human
> readable xml file. Could get big, though...(MD5, I think?). 
> Might be fun to try out in someone's small puzzle type game. oo, oo... if
you 
> wanted real fun you could Zip the xml, so humans who wanted to read it 
> would just WinZip it and life would be good. Hmmmm..

I'm not quite sure what you are getting at here.  I'm envisioning that
instead of having a readily visible Quake.app icon, I have Jeffs Quake and
Paulines Quake icons - double-clicking those load up Quake.app and pre-load
my, or her, preferences and thus open the correct save games, mouse
settings, etc.

The application would install, by default, a "New User" icon which you can
either double-click (and it magically detects that you are requesting that a
new set of user prefs be created), or perhaps you just duplicate it and
rename it.

> > Of course, on Windows, this means needing unique file types 
> (since thats
> how
> > the registry maps files to apps), but on MacOS it works beautifully.
> Better go look up how MacOS works...

Files can have "types" and "owners" which are independent of filename
extensions.  The Finder just "knows" that files owned by "8PBM" (?) should
be opened by Photoshop, files owned by "R*ch" (?) should be opened by
BBEdit, etc.  Each app is supposed to have its own unique signature handed
out by Apple.  MacOS has worked this way since day one.

Windows, on the other hand, just looks in HKCR\(.extension) and does some
arcane indirection through great long CLSID entries before eventually
settling on a command-line it should run, or a DDE message it should send.
Works ok, but restricts the user to having to include extensions like ".doc"

(The only plus side I see to the Windows world comes when I've edited web
pages with DreamWeaver - it saves itself as the owner so double-clicking the
.html file does not load a browser, it loads the editor.  And this is an
annoyance, not much else)

> > The truly innovative could, however, write a tiny app that functioned as
a
> > LAUNCHER, that stored the preferences back into itself as resources, and
> > passed values on perhaps through environment variables, a command-line
> > option or a temporary file.
> That'd be a fun SourceForge project I bet.

To my eye, it'd be a few days work to do the whole thing, given that the
launcher only has to:

a) load and run another application

Since the registry probably has your install directory anyway, its a
registry read, and a ShellExecute()

b) act as a REPOSITORY for preferences

You'd probably do this by having the launcher app have a few documented
entry points that could be accessed via LoadLibrary().

Its up to Brian's library to store the actual preferences into the library
(which he'd do by simply opening the launch application, soft-linking to a
few dynamic entry points and calling them)

Its up to the user of Brian's library to provide UI for the preferences.

Jeff Laing <je...@sp...>
----------------------------------------------------------------------------
---
"Meetings.  Don't we love meetings?  Every day.  Twice a day.  We talk." He
got
on one elbow.  "I bet if I blew the conch this minute, they'd come running.
Then we'd be, you know, very solemn, and someone would say we ought to build
a
jet, or a submarine or a TV set."       -- William Golding, "Lord of the
Flies"

Re: [GD-General] A portable preferences library

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

Brian,
Are you thinking the preferences library will be portable enough to work
for consoles too? Specifically I'm thinking how I could interface this
to the memory card sub-systems on GameCube and PS2. We already have a
preferences implementation for consoles we built by implementing an ANSI
file system compatible interface over the memory card sub-system and it
works pretty well, and the idea we could just have one preferences
library is compelling :-)

Also, I assume most people don't read/write preferences often, but I was
wondering if your library would have the concept of loading all the
prefs in the beginning, then reading/writing them in memory, then
finally flushing them back to non-volatile storage when done?  The
reason for this is that memory cards have a limited lifespan and are
slow to access anyway, so being able to read/write to storage only once
is a good thing.

Brett

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

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

> Because when push comes to shove, Windows is *still* just DOS - it still
> requires a PATH environment variable of ";" seperated directory names to
> search - in fact, with the latest versions of Windows, Microsoft is
> disparaging the idea of putting your DLL's into the system directory, but
> they don't give adequate documentation or support of the API's required to
> insert directories into the search path.
Hmm.. Sooo.. you can't do something like LoadLibrary(MyExeLocation +
\\MyLibrary.dll); ??

> Putting DLL's next to the application that Joe User has to "click to
start"
> makes them a candidate for Joe Jr to trash them (actually, its more likely
> the reverse).
Only if he's an admin(which is the root of so many problems..), and if he
is, he can screw up many more things.

> There *are* registry tricks you can do to auto-force directories into the
> search path, but then there are known bugs where if the path gets too
long,
> it all goes *poof*.
>
> I believe that Application Manifests give you scope to have explicit path
> specs, but that means you need to *write* those at install time and that
> precludes moving things around.
Maybe its my primarily windows upbringing, but I still don't see how that
affects anything when your library is in your executable path.


> Actually you *can't* have many independent instances of an application if
> you are going to respond to double-clicks on a document.  This is the part
> that I feel hasn't been picked up on by developers, and I think its
probably
> because no-one wants to admit that Apple's *LISA* did these things better
> than anyone else.  Documents, and Document Templates are whats important,
> not applications.
>
> Why not have your preferences as the main *ICON* (ie, file) you click to
to
> enter your game?  Feel free to stick it where you like, copy it around if
> you like, but understand that its your config.
That's a fun idea, there. For the adventurous type, you could use the hash
that email uses for binary attachments and shove it all into a human
readable xml file. Could get big, though...(MD5, I think?). Might be fun to
try out in someone's small puzzle type game. oo, oo... if you wanted real
fun you could Zip the xml, so humans who wanted to read it would just WinZip
it and life would be good. Hmmmm..

> For a better user experience, you should do the same with Save Games, and
> they should have a soft-pointer internally to the preferences document so
> that you can restore the users state when they click on this DOCUMENT.
That, or shove it into the XML file as above.

> Of course, on Windows, this means needing unique file types (since thats
how
> the registry maps files to apps), but on MacOS it works beautifully.
Better go look up how MacOS works...

> The truly innovative could, however, write a tiny app that functioned as a
> LAUNCHER, that stored the preferences back into itself as resources, and
> passed values on perhaps through environment variables, a command-line
> option or a temporary file.
That'd be a fun SourceForge project I bet.

> (But, of course, it makes Brian's life a helluva lot harder to write a
> generic prefs class ;-)
Poor Brian. He raises the Noble Cause of a generic preferences class, and we
go off on all sorts of random stuff.

-Dan

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

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

> For what does one need administration rights?  To access the 
> Registry and other protected directories!  

One of which is c:\program files...

Of course you could install things to c:\unprotectedCrap but that rather
misses the point of being able to let your kid brother play with the PC and
be safe in the knowledge he isn't likely to fuck things up.

A lot of people use the auto update functions provided by games, a lot of
peple don't. I tend to be in the latter as I'd rather download such things
at work in the background and bung them on a CD instead of sitting at home
waiting for a game to update itself.

Andy



> -----Original Message-----
> From: Colin Fahey [mailto:cp...@ea...] 
> Sent: 04 December 2003 22:47
> To: gam...@li...
> Subject: Re: [email] RE: [GD-General] A portable preferences library
> 
> 
> 
> 2003 December 4th
> Thursday
> 
> For what does one need administration rights?  To access the 
> Registry and other protected directories!  Well, all of that 
> is unnecessary.
> 
> And as far as patching is concerned...  How do people acquire 
> patches today?  The application itself acquires its own 
> patches! I won't go in to the details of how an application 
> can acquire its own patches and somehow not interefere with 
> the application during the acquisition process, but I think 
> it's pretty evident that this is easy.
> 
> What huge binary "preference" might the user have?  Couldn't 
> this go in the application directory, too?
> 
> As far as my comment about multi-user systems being an 
> antiquated concept, I stand by it, but I need to qualify it.  
> I envision 
> decentralizing all security and preferences; these things 
> become the responsibility of individual resources in cooperation with 
> the operating system.  For example, you could set the 
> "desktop" to "Bob's" preferences, and access one of "Joe's" 
> folders, and launch a media player with "Jane's" preferences. 
>  There is no user logged in to the console, just a cloud of 
> resources with 
> various security mechanisms.
> 
> Right now it is possible for me to create a ZIP archive that 
> is protected by a password.  Even if a hacker compromises my 
> computer and gains access to the ZIP archive, it is pure junk 
> to the hacker. Just expand the idea to everything about the 
> operating system and all applications.
> 
> So a computer may have many users, but the idea of *being* a 
> user on a system and automatically gaining access to resources that 
> you own is obsolete.  Too often the big gatekeeper (e.g., the 
> Windows operating system) is compromised.  Security needs to 
> be decentralized.
> 
> --- 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: [email] RE: [GD-General] A portable preferences library

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

> For what does one need administration rights?  To access the
> Registry and other protected directories!  Well, all of that is
> unnecessary.
Only HKLM and secured directories - which games shouldn't be dealing with
anyway. Same deal with any other OS. It'd be absurd for a game to require
root on a linux box to play, wouldn't it? Yet you should be able to put
games in /bin (I forget where it is under linux) or /Program Files and
expect them to play for all users. Doesn't work with preferences in the exe
directory.

> And as far as patching is concerned...  How do people acquire
> patches today?  The application itself acquires its own patches!
> I won't go in to the details of how an application can acquire
> its own patches and somehow not interefere with the application
> during the acquisition process, but I think it's pretty evident
> that this is easy.
Still doesn't address the need for write access, which is why I personally
shelved that thought.

> What huge binary "preference" might the user have?  Couldn't this
> go in the application directory, too?
>
> As far as my comment about multi-user systems being an antiquated
> concept, I stand by it, but I need to qualify it.  I envision
> decentralizing all security and preferences; these things become
> the responsibility of individual resources in cooperation with
> the operating system.  For example, you could set the "desktop"
> to "Bob's" preferences, and access one of "Joe's" folders, and
> launch a media player with "Jane's" preferences.  There is no
> user logged in to the console, just a cloud of resources with
> various security mechanisms.
Dear god, no. Maybe I'm misunderstanding you, but I'd be pretty irritated at
having to put a password at everything I do. Of course, you *could* get
around that by saving your password somewhere and having the OS do it for
you... that sounds familiar. Or you could be lazy (like people are) and just
use the same password for everything. Which we all know is very secure.

> Right now it is possible for me to create a ZIP archive that is
> protected by a password.  Even if a hacker compromises my computer
> and gains access to the ZIP archive, it is pure junk to the hacker.
> Just expand the idea to everything about the operating system and
> all applications.
So then you want every application to support a robust security system?

> So a computer may have many users, but the idea of *being* a user
> on a system and automatically gaining access to resources that
> you own is obsolete.  Too often the big gatekeeper (e.g., the
> Windows operating system) is compromised.  Security needs to
> be decentralized.
I don't pay a whole lot of attention (I'm behind a firewall, and I keep up
on updates), but generally I see *applications* getting compromised, then
the fact that they are running under Admin access causes problems. Since you
want the applications to run their own security, this problem is in no way
solved.

-Dan

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

[GD-General] RE: A portable preferences library

[Jeff L. <je...@SP...>]

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

Because when push comes to shove, Windows is *still* just DOS - it still
requires a PATH environment variable of ";" seperated directory names to
search - in fact, with the latest versions of Windows, Microsoft is
disparaging the idea of putting your DLL's into the system directory, but
they don't give adequate documentation or support of the API's required to
insert directories into the search path.

Putting DLL's next to the application that Joe User has to "click to start"
makes them a candidate for Joe Jr to trash them (actually, its more likely
the reverse).

There *are* registry tricks you can do to auto-force directories into the
search path, but then there are known bugs where if the path gets too long,
it all goes *poof*.

I believe that Application Manifests give you scope to have explicit path
specs, but that means you need to *write* those at install time and that
precludes moving things around.

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

Actually you *can't* have many independent instances of an application if
you are going to respond to double-clicks on a document.  This is the part
that I feel hasn't been picked up on by developers, and I think its probably
because no-one wants to admit that Apple's *LISA* did these things better
than anyone else.  Documents, and Document Templates are whats important,
not applications.

Why not have your preferences as the main *ICON* (ie, file) you click to to
enter your game?  Feel free to stick it where you like, copy it around if
you like, but understand that its your config.

For a better user experience, you should do the same with Save Games, and
they should have a soft-pointer internally to the preferences document so
that you can restore the users state when they click on this DOCUMENT.

Of course, on Windows, this means needing unique file types (since thats how
the registry maps files to apps), but on MacOS it works beautifully.

The truly innovative could, however, write a tiny app that functioned as a
LAUNCHER, that stored the preferences back into itself as resources, and
passed values on perhaps through environment variables, a command-line
option or a temporary file.

Sure, you can't read them with a text editor, but its meets the
zero-registry-config requirement, its not unreasonable to assume that the
"prefs file be writable", etc...

(But, of course, it makes Brian's life a helluva lot harder to write a
generic prefs class ;-)

Jeff Laing <je...@sp...>
----------------------------------------------------------------------------
--
A complex system designed from scratch never works and cannot be patched up
to
make it work.  You have to start over, beginning with a working simple
system.
                 -- J Gall. "Systemantics: How systems work and how they
fail"

RE: [GD-General] A portable preferences library

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

Yipes, sorry I was thinking of hardware rasterisers.

How time flies :)


> -----Original Message-----
> From: Brian Hook [mailto:ho...@py...] 
> Sent: 04 December 2003 23:10
> To: gam...@li...
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> > To all intents and purposes, it required hardware T&L support.
> 
> This is unequivocally false.  Quake 3 ran very well on 
> vanilla TNT and 
> TNT2 systems.
> 
> Brian
> 
> 

RE: [GD-General] A portable preferences library

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

Indeed, having all important data in once place really is nice. Now if only
all user preferences in applications was as easy to backup or transfer
between PCs :)

AFAIK under Win98/ME most of the CSIDL stuff still works but goes to either
"\Windows\My Documents" or "Windows\profiles\user\My Documents" if you have
profiles setup. It's something like that but it does work. The other benefit
is that if one day the location of user data should change (as was the case
between NT4->Win2K) then providing your app uses these functions then things
will automagically work.

I do actually remember that game thing you're talking about. From what I
recall a percentage of your drive could be allocated for use with games and
their gamedata/persistent storage. Data from less played games would be
evicted as necessary thus if you didn't play "Super FPS 7" for a few months
then the next time you came to play it then you'd be prompted for the
install disks so it could restore it's data.

HD space is dirt cheap these days though so perhaps it was shelved. Sounds
vaguely like what's offered by the xbox though.

A.





> -----Original Message-----
> From: Tom Spilman [mailto:to...@pi...] 
> Sent: 04 December 2003 22:59
> To: gam...@li...
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> > -----Original Message-----
> > Behalf Of Andrew Grant
> 
> > The accepted wisdom for the past few years has been for
> > applications to use SHGet*FolderLocation(), it's certainly 
> > something that Microsoft have been advocating since Win2K 
> > started to become mass market and now with every new consumer 
> > system shipping with a varient of XP it's even more important.
> 
> 	For example some slightly popular games GTA3 and GTA3: 
> Vice City place save games into a directory in the current 
> users My Documents folder.  So does the latest Deus Ex 2 
> demo.  And even though I've uninstalled all three I still 
> have my save games in a place where I can find them and 
> decide to keep or delete them.  Also knowing that I can just 
> backup my documents and just re-install my games Is really 
> nice. Better than each end user becoming an expert in 
> different games particular standard for keeping their data.  
> 
> 	About three years ago I remember speaking to some DX 
> guy about a standard they were working on for PC game 
> installs.  Something about using a fixed percentage of the 
> drive for game installs and it automatically managing it.  
> Anyone remember anything about that or was that a crunch mode 
> delusion?
> 
> 	Also where does SHGetSpecialFolderPath( CSIDL_PERSONAL 
> ) ( My Documents ) go on Win98/ME systems?
> 
> 	Tom
> 
> 

RE: [GD-General] A portable preferences library

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

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

This is unequivocally false.  Quake 3 ran very well on vanilla TNT and 
TNT2 systems.

Brian

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

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

2003 December 4th
Thursday

For what does one need administration rights?  To access the 
Registry and other protected directories!  Well, all of that is
unnecessary.

And as far as patching is concerned...  How do people acquire
patches today?  The application itself acquires its own patches!
I won't go in to the details of how an application can acquire
its own patches and somehow not interefere with the application
during the acquisition process, but I think it's pretty evident
that this is easy.

What huge binary "preference" might the user have?  Couldn't this
go in the application directory, too?

As far as my comment about multi-user systems being an antiquated
concept, I stand by it, but I need to qualify it.  I envision 
decentralizing all security and preferences; these things become
the responsibility of individual resources in cooperation with 
the operating system.  For example, you could set the "desktop"
to "Bob's" preferences, and access one of "Joe's" folders, and
launch a media player with "Jane's" preferences.  There is no
user logged in to the console, just a cloud of resources with 
various security mechanisms.

Right now it is possible for me to create a ZIP archive that is
protected by a password.  Even if a hacker compromises my computer
and gains access to the ZIP archive, it is pure junk to the hacker.
Just expand the idea to everything about the operating system and
all applications.

So a computer may have many users, but the idea of *being* a user
on a system and automatically gaining access to resources that 
you own is obsolete.  Too often the big gatekeeper (e.g., the 
Windows operating system) is compromised.  Security needs to 
be decentralized.

--- Colin

cp...@ea...

RE: [GD-General] A portable preferences library

[Tom S. <to...@pi...>]

> -----Original Message-----
> Behalf Of Andrew Grant

> The accepted wisdom for the past few years has been for 
> applications to use SHGet*FolderLocation(), it's certainly 
> something that Microsoft have been advocating since Win2K 
> started to become mass market and now with every new consumer 
> system shipping with a varient of XP it's even more important.

	For example some slightly popular games GTA3 and GTA3: Vice City
place save games into a directory in the current users My Documents
folder.  So does the latest Deus Ex 2 demo.  And even though I've
uninstalled all three I still have my save games in a place where I can
find them and decide to keep or delete them.  Also knowing that I can
just backup my documents and just re-install my games Is really nice.
Better than each end user becoming an expert in different games
particular standard for keeping their data.  

	About three years ago I remember speaking to some DX guy about a
standard they were working on for PC game installs.  Something about
using a fixed percentage of the drive for game installs and it
automatically managing it.  Anyone remember anything about that or was
that a crunch mode delusion?

	Also where does SHGetSpecialFolderPath( CSIDL_PERSONAL ) ( My
Documents ) go on Win98/ME systems?

	Tom

RE: [GD-General] A portable preferences library

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

I haven't been to the last few, but some of the presentations at Meltdown
were always pretty good sources of "do's & don'ts" to ensure your
application would play nicely with current and upcoming versions of Windows.

Most of them are avaiable on the web, for example here's one I remember
containing some information about things your game shouldn't do if you want
it to play nicely with the Fast User Switching which would be introduced in
(the then upcoming) XP.

http://www.microsoft.com/mscorp/corpevents/meltdown2001/ppt/GamingWinXP.ppt




> -----Original Message-----
> From: Andrew Grant [mailto:ag...@cl...] 
> Sent: 04 December 2003 22:10
> To: 'gam...@li...'
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> The accepted wisdom for the past few years has been for 
> applications to use SHGet*FolderLocation(), it's certainly 
> something that Microsoft have been advocating since Win2K 
> started to become mass market and now with every new consumer 
> system shipping with a varient of XP it's even more important.
> 
> GetWindows/System directory are definitely things an 
> application shouldn't be writing to in the normal course of 
> its operation... The common paths exposed via environment 
> variables (some of them at least!) are useful for batch files 
> & scripts.
> 
> 
> _____________________________________
> andrew grant | programmer | climax brighton
> ag...@cl... - www.climax.co.uk
> 
> 
> 

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

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

I was actually refering to having to patch multiple versions of a game, and
the fact many patch installers check the registry for the game location and
current version before doing anything.

I completely agree about the DLL and copy protection things though.



> -----Original Message-----
> From: Dan Thompson [mailto:da...@ar...] 
> Sent: 04 December 2003 22:18
> To: gam...@li...
> Subject: Re: [email] RE: [GD-General] A portable preferences library
> 
> 
> However, the analogy completely breaks down with patches, 
> because little johnny doesn't have write access in the 
> example. Since we are talking about preferences, anyway, for 
> this arguement I'll just say patching is done by admins. 
> Actually the copy on write method, while taking an obscene 
> amount of space, is the most transparent out of everything 
> I've seen, and even handles patching (yay). Of course it 
> would have to be OS level, then you get into arguements about 
> where it goes, etc.
> 
> Regarding the discussion about dlls and stuff in the windows 
> directory, I can't really convince myself its all MS's fault. 
> No one is forcing people to use the windows directory for 
> dlls, and if people would just use HKCU/Software/Company/Game 
> for keys, it wouldn't really be that bad. Its the <insert the 
> worst name you can call someone for your language here, and 
> make it plural> who write random stuff as a "copy protection" 
> who make life miserable.
> 
> Speaking of copy protection, I actually had to use the CD 
> crack in order to play Max Payne 2 - because the protection 
> meant to prevent such things kept the game from working! 
> Isn't that FUNNY!? *twitch*
> 
> -Dan
> 

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

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

However, the analogy completely breaks down with patches, because little
johnny doesn't have write access in the example. Since we are talking about
preferences, anyway, for this arguement I'll just say patching is done by
admins. Actually the copy on write method, while taking an obscene amount of
space, is the most transparent out of everything I've seen, and even handles
patching (yay). Of course it would have to be OS level, then you get into
arguements about where it goes, etc.

Regarding the discussion about dlls and stuff in the windows directory, I
can't really convince myself its all MS's fault. No one is forcing people to
use the windows directory for dlls, and if people would just use
HKCU/Software/Company/Game for keys, it wouldn't really be that bad. Its the
<insert the worst name you can call someone for your language here, and make
it plural> who write random stuff as a "copy protection" who make life
miserable.

Speaking of copy protection, I actually had to use the CD crack in order to
play Max Payne 2 - because the protection meant to prevent such things kept
the game from working! Isn't that FUNNY!? *twitch*

-Dan

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


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

The accepted wisdom for the past few years has been for applications to use
SHGet*FolderLocation(), it's certainly something that Microsoft have been
advocating since Win2K started to become mass market and now with every new
consumer system shipping with a varient of XP it's even more important.

GetWindows/System directory are definitely things an application shouldn't
be writing to in the normal course of its operation... The common paths
exposed via environment variables (some of them at least!) are useful for
batch files & scripts.


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








> -----Original Message-----
> From: Brian Hook [mailto:ho...@py...] 
> Sent: 04 December 2003 21:57
> To: gam...@li...
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> > 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
> 
> 
> 
> 
> -------------------------------------------------------
> 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_idU7
>