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