22 Mar
2005
22 Mar
'05
9:21 a.m.
James Hawkins wrote:
>Nobody's working on it, so it won't be
supported until someone cares
>enough to do it. I encouraged a few people to start working on it but
>nobody did, so taking out the existing support is a way to provide
>more encouragement. If that's not enough then the feature simply won't
>be supported anymore.
>
>
I started toying around the current and old code, Gathering knowledge
and ideas. What I think of doing is:
keep the boot registry as is (more less). Put in on wine/wine/config a
key system that enables a "plugin" system of registry loaders/savers.
Builtin plugins are current format and Windows binary format. Other
formats could be easily implemented; candidates could be XML, MySQL etc...
The system I thought of would also save the hives and sub trees, to the
files/plugins it was loaded from. Each plugin could also implement a
write behind so Data don't get lost in case of a crash or power lost.
Good point with the on demand-loading/cache of keys. It should be done
this way. So in summary:
1. Implement a Memory registry with plugin drivers and mount semantics.
This driver goes here, that driver mounts there.
2. Implement 2 basic drivers: Wine builtin format, Windows binary format.
3. Enable dynamic load of external drivers.
The Initial registry system is always loaded from system.reg builtin
format which is also the "fstab" file of the registry. At minimum every
thing is exactly like now one (two) files builtin format, and that's it.
At the maximum it can be highly object oriented with per user, per
application, per group management.
Please tell me what you think.
Any libraries I should look into?
How is ReactOS's current (future) system?
Free Life
Boaz