Re: [GD-General] RE: SetDLLDirectory()

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

> significant number of sales for that to be worth while).  I don't
> know what Brian intends for his "general library" but I'm betting
> that supporting "just the latest variant of Windows" may not be his
> aim.

Well, my original goals were quite simple, but then after this 
discussion, they've become muddied =3D)

I've since changed it to prefer using a file system.  It simply stores 
into INI-style preference files that are ASCII.  Binary data is 
converted (inefficiently) to ASCII data (i.e. 0xBC =3D> "BC").

Preferences can be saved as user local, system wide or application 
common.  

The default implementation is mostly done, and it's extremely slow, 
but it's readable, which is what's important for a project like this.  
I'm going to finish it up and put it up on CVS when I get a chance.  
The biggest problem will be suitable testing.

And yes, I could have used Lua, but that would have been drastic 
overkill for something like this, especially since the availability of 
OS-specific preferences is still something I'd like to support (Win32 
registry and OS X Preferences).  I'm in the camp that a file is better 
than some registry setting, but I'd rather not dictate policy, just 
provide an abstraction that lets others make that choice as they see 
fit.

It's all endian safe (in theory, testing will bear this out one way or 
another).  I've actually been bitten by the situation where a 
preference file is shared on the same file system by two different 
implementations.  NingPo Mah Jong would do an endian-unsafe fwrite of 
its high scores structure, but I didn't care about the endianess since 
I didn't conceive of a situation where you would write it out one way 
and then need to read it back another.

Of course, as with so many assumptions, I was wrong =3D)  In this 
particular case, there was a filesystem shared between Linux/x86 and 
Sparc Solaris, and so the prefs were written out in Linux, then read 
back when someone was using the Sparc implementation and...ka-boom.

Brian