Windows registry diffs

Is there a *simple* means (I've already found a complicated one)
of noting the changes made to the registry by installing X vs. Y?

(Consider the different cases:  install X, then Y vs. Y then X)

On 13/11/16 19:34, Don Y wrote:
> Is there a *simple* means (I've already found a complicated one)
> of noting the changes made to the registry by installing X vs. Y?
>
> (Consider the different cases:  install X, then Y vs. Y then X)

You haven't said what your "complicated means" is, so I have no idea 
whether or not you have already considered and dismissed what I would 
consider the "simple" means:

Export the registry (or relevant part of it) as text, do the install, 
export it again, and run WinMerge or WinDiff on the two files.

Alternatively, there are a hundred and one free "registry difference" 
tools to be found by google.  I haven't used any, and can't give any 
recommendations.

If you want to get the best information about the differences in this 
sort of thing, do your installations in a Virtual Box system.  Take a 
snapshot before installing - then you can roll back easily and try the 
installation in a different order.

On 11/13/2016 12:43 PM, David Brown wrote:
> On 13/11/16 19:34, Don Y wrote:
>> Is there a *simple* means (I've already found a complicated one)
>> of noting the changes made to the registry by installing X vs. Y?
>>
>> (Consider the different cases:  install X, then Y vs. Y then X)
>
> You haven't said what your "complicated means" is, so I have no idea whether or
> not you have already considered and dismissed what I would consider the
> "simple" means:
>
> Export the registry (or relevant part of it) as text, do the install, export it
> again, and run WinMerge or WinDiff on the two files.
>
> Alternatively, there are a hundred and one free "registry difference" tools to
> be found by google.  I haven't used any, and can't give any recommendations.
>
> If you want to get the best information about the differences in this sort of
> thing, do your installations in a Virtual Box system.  Take a snapshot before
> installing - then you can roll back easily and try the installation in a
> different order.

The latter is what I presently do; it's not enough to track:
Virgin Machine -> Install X -> Install Y
(i.e., TWO changes to the registry)
    vs.
Virgin Machine -> Install Y -> Install X
(i.e., two OTHER changes to the registry)

It would be nicer if the registry could be imaged and moved aside
before the first such install, then compared to the registry
after the first AND second installs.

(I think I have a way of doing this but it is brittle)

On 13.11.2016 г. 22:12, Don Y wrote:
> On 11/13/2016 12:43 PM, David Brown wrote:
>> On 13/11/16 19:34, Don Y wrote:
>>> Is there a *simple* means (I've already found a complicated one)
>>> of noting the changes made to the registry by installing X vs. Y?
>>>
>>> (Consider the different cases:  install X, then Y vs. Y then X)
>>
>> You haven't said what your "complicated means" is, so I have no idea
>> whether or
>> not you have already considered and dismissed what I would consider the
>> "simple" means:
>>
>> Export the registry (or relevant part of it) as text, do the install,
>> export it
>> again, and run WinMerge or WinDiff on the two files.
>>
>> Alternatively, there are a hundred and one free "registry difference"
>> tools to
>> be found by google.  I haven't used any, and can't give any
>> recommendations.
>>
>> If you want to get the best information about the differences in this
>> sort of
>> thing, do your installations in a Virtual Box system.  Take a snapshot
>> before
>> installing - then you can roll back easily and try the installation in a
>> different order.
>
> The latter is what I presently do; it's not enough to track:
> Virgin Machine -> Install X -> Install Y
> (i.e., TWO changes to the registry)
>     vs.
> Virgin Machine -> Install Y -> Install X
> (i.e., two OTHER changes to the registry)
>
> It would be nicer if the registry could be imaged and moved aside
> before the first such install, then compared to the registry
> after the first AND second installs.
>
> (I think I have a way of doing this but it is brittle)
>

Hi Don,
my reply is no help but while at it I would like some opinions
by people more familiar with the windows registry format.

Recently I introduced a sort of equivalent of it to dps, I call
it a "global store". Via the runtime object system one can create/
read/write/delete records, paths etc. Entries are of various types,
(e.g. signed byte, unsigned long, dual, quad, list of objects (e.g.
string) etc.). Works fine.
I have implemented it on top of the dps file system, it is an
image of a "disk" with a 64 byte long cluster (i.e. even if and entry is
a byte it will take up 64 bytes).
How is this on other systems (e.g. the windows registry)? Does this
granularity sound overblown (most records if non-text will be 4 or 8
bytes I guess, it is barely in use yet)? For text it is OK, then much
of the space will be taken up by all the directory entries, but I am
still a bit uneasy about it hence I ask for some more thoughts.
OTOH being on top of the file system makes a lot of things quite
easy (no need to explain the how and why, it will be obvious to
everyone here).

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On 11/13/2016 1:35 PM, Dimiter_Popoff wrote:
> my reply is no help but while at it I would like some opinions
> by people more familiar with the windows registry format.
>
> Recently I introduced a sort of equivalent of it to dps, I call
> it a "global store". Via the runtime object system one can create/
> read/write/delete records, paths etc. Entries are of various types,
> (e.g. signed byte, unsigned long, dual, quad, list of objects (e.g.
> string) etc.). Works fine.

Yes, I use a real RDBMS for similar purposes -- I have *no* filesystem
accessible to applications (the RDBMS is the ONLY persistent store!)

> I have implemented it on top of the dps file system, it is an
> image of a "disk" with a 64 byte long cluster (i.e. even if and entry is
> a byte it will take up 64 bytes).
> How is this on other systems (e.g. the windows registry)? Does this
> granularity sound overblown (most records if non-text will be 4 or 8
> bytes I guess, it is barely in use yet)? For text it is OK, then much
> of the space will be taken up by all the directory entries, but I am
> still a bit uneasy about it hence I ask for some more thoughts.
> OTOH being on top of the file system makes a lot of things quite
> easy (no need to explain the how and why, it will be obvious to
> everyone here).

AFAICT, the Windows Registry is a binary file having a much more complex
structure to encode the relationships between keys, subkeys, values, etc.
There are also kludges added (as afterthoughts) to "fix" problems that
weren't anticipated (or, were anticipated but not adequately HANDLED!)
in the earlier versions of the interface.

[As Windows has to ensure the API is backward compatible, these kludges
ensure legacy apps can "misbehave" without compromising advances in the
security/privilege models of newer Windows releases]

 From my understanding of your product, *you* are the only one who
will be accessing your "global store"/registry.  (I'm not even sure
you will be exposing it in its native form to users!  I.e., it is
possible that YOUR applications will be the *exclusive* gateways to
specific "registry entries")

This can be important!

E.g., in my case, 3rd parties can add things to my "registry" so I can't
control the names they choose for keys/values.  Additionally, they may
need/want to access stuff that my or other apps have created.  The
point being, *I* have to accept an attempt to resolve "MySetting" *or*
"MySettnig" [sic] -- both can be legitimate!  If the second example is,
in fact, a misspelling, then I have to return an error/not found.
Likewise, I can allow the user to create that misspelled variant as
an independent entry (from the more likely spelling).

You, OTOH, (if you are exclusive accessor) can "know" that you will never
misspell the name of a key -- nor access a nonexistent key.  So, you can
possibly use a *hash* of the key name to access a value stored in a binary
file instead of treating each entry as a mini-64-byte-file.  Because you
KNOW that "MySetting" is the ONLY way you will ever access that particular
stored entry (and don't have to worry about other users/applications
screwing up and trying to access "MySettnig".

[Do you see what I'm saying?]

Likewise, you can encode the size of an entry in the name (or the portion of
the file in which it is stored:  all bools are in the first part of the file;
all longwords in the second part; all strings in the third part; etc.)

Finally, you have to consider how often you will be accessing these contents
and whether or not you can afford to cache much/all of the "store" in live
memory -- instead of going back to the medium for each access.

<shrug>  HTH

On 14/11/16 07:35, Dimiter_Popoff wrote:
> On 13.11.2016 г. 22:12, Don Y wrote:
>> On 11/13/2016 12:43 PM, David Brown wrote:
>>> On 13/11/16 19:34, Don Y wrote:
>>>> Is there a *simple* means (I've already found a complicated one)
>>>> of noting the changes made to the registry by installing X vs. Y?
>>>>
>>>> (Consider the different cases:  install X, then Y vs. Y then X)
>>>
>>> You haven't said what your "complicated means" is, so I have no idea
>>> whether or
>>> not you have already considered and dismissed what I would consider the
>>> "simple" means:
>>>
>>> Export the registry (or relevant part of it) as text, do the install,
>>> export it
>>> again, and run WinMerge or WinDiff on the two files.
>>>
>>> Alternatively, there are a hundred and one free "registry difference"
>>> tools to
>>> be found by google.  I haven't used any, and can't give any
>>> recommendations.
>>>
>>> If you want to get the best information about the differences in this
>>> sort of
>>> thing, do your installations in a Virtual Box system.  Take a snapshot
>>> before
>>> installing - then you can roll back easily and try the installation in a
>>> different order.
>>
>> The latter is what I presently do; it's not enough to track:
>> Virgin Machine -> Install X -> Install Y
>> (i.e., TWO changes to the registry)
>>     vs.
>> Virgin Machine -> Install Y -> Install X
>> (i.e., two OTHER changes to the registry)
>>
>> It would be nicer if the registry could be imaged and moved aside
>> before the first such install, then compared to the registry
>> after the first AND second installs.
>>
>> (I think I have a way of doing this but it is brittle)
>>
>
> Hi Don,
> my reply is no help but while at it I would like some opinions
> by people more familiar with the windows registry format.
>
> Recently I introduced a sort of equivalent of it
...
> I have implemented it on top of the dps file system,

I don't know DPS, but that doesn't sound completely nuts,
as long as DPS is journalled (though I expect, only on
the directory structure, not the contents). Personally if
I had to use a filesystem I'd use a "content store" of
immutable objects like the back end of GIT though.

However, by far the most widespread solution used to this
incredibly common problem is to use SQLite. Never mind that
it's SQL, the underlying storage technology is some of the
most heavily tested and reliable code that has ever been
written. It's fully journalled, and the automated test
platform simulates *every* point of failure (every error
path) in the entire codebase, for every platform, on every
release.

SQLite is small enough that it gets used in almost every
phone app, as well as larger things like web browsers.
I don't think I've ever heard of a failure that resulted
initially from corruption of such a database, and that's
almost incredible by itself.

Read more about their testing strategy here, it's admirable:
<https://www.sqlite.org/testing.html>

Clifford Heath.

On 14.11.2016 г. 01:21, Don Y wrote:
> On 11/13/2016 1:35 PM, Dimiter_Popoff wrote:
> ....
>
>  From my understanding of your product, *you* are the only one who
> will be accessing your "global store"/registry.

Well yes but this may not be the case forever, at least I have to think
so.

> (I'm not even sure
> you will be exposing it in its native form to users!  I.e., it is
> possible that YOUR applications will be the *exclusive* gateways to
> specific "registry entries")
>
> This can be important!

So far I use it to store application related data - e.g. its first
use was to store the sizes of a few user editable frames in a window
showing a particular dps object (more precisely file browser column
widths, pretty much like other file browsers do it).
The app - rather, the dps object, it can be "run" by any task - knows
its path and has to use it to access "parameters" - which are really
files, here is the output of "dir" for our example:

#FDK\F:ALL\programs\tgi\common_browser\objects\dir_view_details\
column_widths         12 08.10.16/03:31:31 USER
1 file(s), 12 ($C) bytes total.

Knowing the path one can "getrec" or "putrec"; the record comes
with data type (in this case a dual - 64 bit - unsigned which
actually contains 4 16 bit column widths, the 3-d long is
for the type/unit specification, pretty much old and standard
within dps objects).

You can do this from a shell command line, too (not like I did
it with "dir", this was just to discover what I did not remember;
you can ask the "global_store" to get you the record in one or
two lines if you have the complete path).

>
> You, OTOH, (if you are exclusive accessor) can "know" that you will never
> misspell the name of a key -- nor access a nonexistent key.  So, you can
> possibly use a *hash* of the key name to access a value stored in a binary
> file instead of treating each entry as a mini-64-byte-file.  Because you
> KNOW that "MySetting" is the ONLY way you will ever access that particular
> stored entry (and don't have to worry about other users/applications
> screwing up and trying to access "MySettnig".

Well I have been doing that sort of thing many times, generally this is
how apps/objects store state etc. It has been standardized for years,
that type/unit thing works via getxpar/setxpar on objects, also doable
from a shell script if you know the object location, and accessible via
the parameter "index" (what you refer to as a "hash"); the index, OTOH,
can be located by name (if you do this from a command line and not
from within code you write).

All this is fine but it takes a file to save the settings to which
is unique to any application. With the global store I want to give
objects/applications the option to have a standardized location for
such sort of thing; it does not get in conflict with the other one,
e.g. an object can locate an entry in it pointing to a file where
the settings of interest are etc.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On 14.11.2016 г. 01:52, Clifford Heath wrote:
> On 14/11/16 07:35, Dimiter_Popoff wrote:
> .....
>> Hi Don,
>> my reply is no help but while at it I would like some opinions
>> by people more familiar with the windows registry format.
>>
>> Recently I introduced a sort of equivalent of it
> ...
>> I have implemented it on top of the dps file system,
>
> I don't know DPS, but that doesn't sound completely nuts,
> as long as DPS is journalled (though I expect, only on
> the directory structure, not the contents).

In dps a directory can just be copied like any other file
and it will still point to the correct file entries at that
moment; it is not done automatically but I have done it in
the past. Then one can copy the directory file and set the
type of the copy to be non-directory so it won't confuse
the system by its duplicate pointers etc.
It is probably quite different from other filesystems as I
have done it without looking at many of them.

> Personally if
> I had to use a filesystem I'd use a "content store" of
> immutable objects like the back end of GIT though.

I believe my equivalent to this would be to use the directory
entry to store data into rather than a pointer to a file.
A directory entry in dps can store two SDW (segment descriptor
word, starting_block:length each, a total of 4 longwords); I
did this ages ago in order to be able to access files which
are in up to two pieces directly from the directory entry,
if more pieces are involved then the directory entry points
to a RIB (retrieve information block, a list of SDW-s).

Now this would save me the 64 bytes for a file; but I'll have
to introduce another file type (there is room for that but
obviously I am cautious with such a step) which would
be treated as "null file". Not such a huge step now that I
think of it. But I'll leave it for later, it will not be
hard to change to it when I want to get rid of the 64 byte
file contents (the longnamed directory entry is very efficient
in that it is of variable length, depending on the name length,
e.g. a 7 character name takes 3 longwords, an 11 char. name
takes 4 etc.).


>
> However, by far the most widespread solution used to this
> incredibly common problem is to use SQLite. Never mind that
> it's SQL, the underlying storage technology is some of the
> most heavily tested and reliable code that has ever been
> written. It's fully journalled, and the automated test
> platform simulates *every* point of failure (every error
> path) in the entire codebase, for every platform, on every
> release.
>
> SQLite is small enough that it gets used in almost every
> phone app, as well as larger things like web browsers.
> I don't think I've ever heard of a failure that resulted
> initially from corruption of such a database, and that's
> almost incredible by itself.
>
> Read more about their testing strategy here, it's admirable:
> <https://www.sqlite.org/testing.html>

Thanks for the pointer (to SQL), I'll look into what it does
for ideas. I won't use it - so far all dps code is my own and
I want it to stay like this for now - but I can certainly have
a look at it to see how other people do it.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

Hi Dimiter,

On 11/14/2016 3:56 AM, Dimiter_Popoff wrote:
> On 14.11.2016 г. 01:21, Don Y wrote:
>> On 11/13/2016 1:35 PM, Dimiter_Popoff wrote:
>> ....
>>
>>  From my understanding of your product, *you* are the only one who
>> will be accessing your "global store"/registry.
>
> Well yes but this may not be the case forever, at least I have to think
> so.

OK.  In my case, this was an anticipated need from the project's
conception.

And, not just "settings" but any "object" in which an application
might have an interest.  E.g., "songs" are stored in the presistent
store, not just the name and artist *of* a song.  So, an application
retrieves a song -- or set of songs -- by issuing a suitable query
to the RDBMS:
     SELECT song FROM music_archive
     WHERE artist="Montenegro, Hugo"
     ORDER BY duration
This being different than requesting a list of song *titles*:
     SELECT title FROM music_archive
     WHERE artist="Montenegro, Hugo"
     ORDER BY duration

However, as a central (exclusive) repository, it also gives me
a "whiteboard" through which changes to these objects can be
broadcast to interested parties.  For example, if a user's
physical location changes, it can be updated in the database
and any "clients/consumers" interested in that information
can be notified that it has been updated (so they can adjust
their services accordingly).

>> (I'm not even sure
>> you will be exposing it in its native form to users!  I.e., it is
>> possible that YOUR applications will be the *exclusive* gateways to
>> specific "registry entries")
>>
>> This can be important!
>
> So far I use it to store application related data - e.g. its first
> use was to store the sizes of a few user editable frames in a window
> showing a particular dps object (more precisely file browser column
> widths, pretty much like other file browsers do it).

But, presumably, that data can be of varying sizes?  E.g., if you
had need to store an IPv6 address or a 128 pixel "icon" (selected
by the user to represent <something>), could you seemlessly accommodate
this by allocating multiple "clusters"?  Likewise, accommodating objects
of varying sizes (like "notes" from users)?

> The app - rather, the dps object, it can be "run" by any task - knows
> its path and has to use it to access "parameters" - which are really
> files, here is the output of "dir" for our example:
>
> #FDK\F:ALL\programs\tgi\common_browser\objects\dir_view_details\
> column_widths         12 08.10.16/03:31:31 USER
> 1 file(s), 12 ($C) bytes total.
>
> Knowing the path one can "getrec" or "putrec"; the record comes
> with data type (in this case a dual - 64 bit - unsigned which
> actually contains 4 16 bit column widths, the 3-d long is
> for the type/unit specification, pretty much old and standard
> within dps objects).

In my case, the objects are fields in tables instead of in a
hierarchical namespace (pathname+filename).  So, returning to the
music example, above, one table might enumerate "groups" (e.g.,
The Beatles) while another enumerates "artists" (i.e., "Lennon",
"Harrison", etc.) and still another ties "artists" to "groups"
(keeping in mind that an artist can belong to multiple groups
concurrently and over time).

So, an "album" can call out a set of "songs", each having a specific
"duration", music written by one or more "artists", with lyrics
written by some *other* artist -- and performed by a particular
"group", etc.

> You can do this from a shell command line, too (not like I did
> it with "dir", this was just to discover what I did not remember;
> you can ask the "global_store" to get you the record in one or
> two lines if you have the complete path).
>
>> You, OTOH, (if you are exclusive accessor) can "know" that you will never
>> misspell the name of a key -- nor access a nonexistent key.  So, you can
>> possibly use a *hash* of the key name to access a value stored in a binary
>> file instead of treating each entry as a mini-64-byte-file.  Because you
>> KNOW that "MySetting" is the ONLY way you will ever access that particular
>> stored entry (and don't have to worry about other users/applications
>> screwing up and trying to access "MySettnig".
>
> Well I have been doing that sort of thing many times, generally this is
> how apps/objects store state etc. It has been standardized for years,
> that type/unit thing works via getxpar/setxpar on objects, also doable
> from a shell script if you know the object location, and accessible via
> the parameter "index" (what you refer to as a "hash"); the index, OTOH,
> can be located by name (if you do this from a command line and not
> from within code you write).
>
> All this is fine but it takes a file to save the settings to which
> is unique to any application. With the global store I want to give
> objects/applications the option to have a standardized location for
> such sort of thing; it does not get in conflict with the other one,
> e.g. an object can locate an entry in it pointing to a file where
> the settings of interest are etc.

In my case, I wanted to ensure that an object's identity and integrity
are preserved and enforced.  E.g., you can't change an "IP_address"
field to "128.0.1.935" -- nor can you change it to "3.14159265"
or "Mrs Vandertamp".  Any client authorized to make changes to a
setting is still constrained to ensure the resulting change ALWAYS
remains valid.  This means that anyone *looking* at a value
inherently knows the value is legitimate.

So, unlike "configuration files" (e.g., Windows' .INI files), you
don't have to parse a file and understand all of its potential
syntax in order to access a specific "setting" contained within;
you just have to know its "name" (where to find it in a table).

[Too many systems have arbitrary rules regarding syntax and other
"rules" for "configuration files":
- are comments allowed?
- WHERE are the comments allowed (can they be WITHIN a line)?
- what characters are treated as whitespace?
- are values expected in decimal/hex/etc.?
- what values are valid for each particular setting?
   (e.g., can I use "Bob" as a foreground color??)
- are CRLF's treated like newlines?
- what if the file doesn't END in a newline?
- who is allowed to make changes to the file?
- how are changes (and changers!) tracked*?
- how do I notify clients of changes in THIS file?  Or, do they
   have to poll it, periodically?
etc.]

On 11/14/2016 4:19 AM, Dimiter_Popoff wrote:
> On 14.11.2016 г. 01:52, Clifford Heath wrote:
>> On 14/11/16 07:35, Dimiter_Popoff wrote:

>>> Recently I introduced a sort of equivalent of it
>> ...
>>> I have implemented it on top of the dps file system,
>>
>> I don't know DPS, but that doesn't sound completely nuts,
>> as long as DPS is journalled (though I expect, only on
>> the directory structure, not the contents).
>
> In dps a directory can just be copied like any other file
> and it will still point to the correct file entries at that
> moment; it is not done automatically but I have done it in
> the past. Then one can copy the directory file and set the
> type of the copy to be non-directory so it won't confuse
> the system by its duplicate pointers etc.
> It is probably quite different from other filesystems as I
> have done it without looking at many of them.

I suspect you'd have the same sort of problem I'm currently
encountering with the Windows Registry:  how could you
"painlessly" track changes made to your "global store",
"who" (which process) made them AND easily "undo" them.

I've been amused to discover that this *is* possible under
Windows; but, much harder under my formal RDBMS implementation!
Especially the "undo them" (well, maybe I could build a giant
"transaction" around everything but I'm willing to be the
RDBMS would die when faced with an open-ended issue like that!)

A solution for *you* might be to physically make a recrusive
copy of your global store's root folder "off to the side,
somewhere" -- then, use that to replace the modified store
later, to return it to its original contents.  (?)

>> Personally if
>> I had to use a filesystem I'd use a "content store" of
>> immutable objects like the back end of GIT though.
>
> I believe my equivalent to this would be to use the directory
> entry to store data into rather than a pointer to a file.
> A directory entry in dps can store two SDW (segment descriptor
> word, starting_block:length each, a total of 4 longwords); I
> did this ages ago in order to be able to access files which
> are in up to two pieces directly from the directory entry,
> if more pieces are involved then the directory entry points
> to a RIB (retrieve information block, a list of SDW-s).

This approach is used to store "symbolic links"; i.e., use
the directory entry to store a text pathname to the linked
file (if the pathname is short enough to fit *in* a
directory entry) without incurring other filesystem costs
(i.e., a real data block)

E.g., if a directory entry is supposed to symbolically reference
some other point in the filesystem hierarchy:
       file1
       folder/
            file2   -> /file1
            file3
the "link" to "/file1" is stored in the dirent for "file2"
*as* "/file1" so it carries no real overhead beyond that of its
name ("file2")

> Now this would save me the 64 bytes for a file; but I'll have
> to introduce another file type (there is room for that but
> obviously I am cautious with such a step) which would
> be treated as "null file". Not such a huge step now that I
> think of it. But I'll leave it for later, it will not be
> hard to change to it when I want to get rid of the 64 byte
> file contents (the longnamed directory entry is very efficient
> in that it is of variable length, depending on the name length,
> e.g. a 7 character name takes 3 longwords, an 11 char. name
> takes 4 etc.).
>
>> However, by far the most widespread solution used to this
>> incredibly common problem is to use SQLite. Never mind that
>> it's SQL, the underlying storage technology is some of the
>> most heavily tested and reliable code that has ever been
>> written. It's fully journalled, and the automated test
>> platform simulates *every* point of failure (every error
>> path) in the entire codebase, for every platform, on every
>> release.
>>
>> SQLite is small enough that it gets used in almost every
>> phone app, as well as larger things like web browsers.
>> I don't think I've ever heard of a failure that resulted
>> initially from corruption of such a database, and that's
>> almost incredible by itself.
>>
>> Read more about their testing strategy here, it's admirable:
>> <https://www.sqlite.org/testing.html>
>
> Thanks for the pointer (to SQL), I'll look into what it does
> for ideas. I won't use it - so far all dps code is my own and
> I want it to stay like this for now - but I can certainly have
> a look at it to see how other people do it.

There are other "lightweight, connectionless" schemes to maintain
simple data in a "file-like hive".  Some ~20 years ago, I was
fond of "db" (and dbm/ndbm).  But, they didn't have the full
relational capabilities of more modern implementations
(I'm not sure that capability would benefit you in your usage;
its helpful for me as very few actions do NOT involve a variety
of JOINs)

I find this a real win in many cases in that it lets less privileged
clients "augment" other "restricted" tables by joining to the
existing table and creating fields/columns that map to it in their
own *private* tables; AS IF the original, privileged table contained
those fields AND THEY WERE ALTERable BY THE CLIENT.

E.g., imagine your "window position" settings didn't want to be
alterable by "other", less privileged processes/clients.  But,
that you wanted to associate another field with each window:
"decoration color" for the various controls/decorations that
are associated with a window (frame).  Like a "close" control,
"minimize", etc.

The client that wants to maintain/access that data could create
another table with two columns:
- decoration color
- reference to window
So, to that client, the actual "database" would look like
a series of (window, position, decoration) tuples -- because the
query would automatically "resolve" the "reference to window"
and make the contents of that original table effectively part
of this new table (view).

The client wouldn't be able to modify the "position" of any
of those tuples (because the ACL's of the other table would
prohibit it's write-access), BUT, it could freely update the
"decoration" field -- without the "original process" even
knowing that this field had been tacked on!