If it seems I come down a bit hard on the proposal, I can only blame language barriers. My intention is only to illuminate some of the pitfalls I think are inherent in a dynamic load system as the proposed.
Boaz Harrosh wrote:
What I think of doing is: keep the boot registry as is (more less).
This is, I believe, not an area open for discussion. It is as it is. If this is correct, then basically all of HKLM\SYSTEM (and linked keys) are off-limit.
Put in on wine/wine/config a key system that enables a "plugin" system of registry loaders/savers.
A couple of questions:
SAM? How is security supposed to be handled using this approach - assuming SAM is to handle the security (which I must assume, else I'm against this)?
Links? Especially links pointing to another "handler".
Volatile keys?
Builtin plugins are current format and Windows binary format. Other formats could be easily implemented; candidates could be XML, MySQL etc...
Having seen the amount of registry lookups the NT5.0 (aka Windows 2000) Explorer does just for viewing a single directory, I suspect running that over an SQL client to a server (or even parsing a local XML file) one might be in for a treat making making Windows XP on Bochs, on a 486, look fast.
I might also point out the fact that registry-handling is currently done entirely from kernel mode, with unrestricted access rights. Would you trust an XML parser or an SQL client these unrestricted rights? I know for certain I wouldn't.
One could, theoretically, solve this by having such things run as services (in user-mode, and under restricted accounts), and have the kernel call out to them using RPC (how to establish trust between the kernel and such serices? LPC is out of the question I think) - opening the door for effectively making a system look hung if one of the servers this would depend upon was unavailable. Again, think Explorer.exe and its gazillion registry accesses.
The system I thought of would also save the hives and sub trees, to the files/plugins it was loaded from.
If a plugin has started handling a key, it would (obviously) have to handle all sub-keys too - even if delegating deeper down.
Each plugin could also implement a write behind so Data don't get lost in case of a crash or power lost.
If this is to be a serious proposal, it would have to provide loggin mechanisms. As it would be basically impossible to hold data consistency across networks, SQL servers and stuff, the data would have to be stored in a log on the boot volume (if for nothing else, to assure correct order of updates).
Good point with the on demand-loading/cache of keys. It should be done this way.
It might seem reasonable at first, but saying it _should_ be this way without any data to back it up seems a bit premature. I haven't seen any empirical data to back it up, and no testing for what happens when e.g. any other part of the system encounters a catastrophic failure (the "system" is now extended to include network, routers and even remote SQL servers).
I suspect (with a bit of experience in the area) that this might actually be completely unsatisfactory, and that it in fact should grab the whole hive(s) from the remote storage, storing it/them locally, to allow for network outages without hanging the whole system or crashing apps.
So in summary:
- Implement a Memory registry with plugin drivers and mount semantics.
Please define "Memory registry". Please keep in mind that the registry on Windows machines are nowadays (especially if you install .NET) of such a size as to require more storage than you needed RAM to boot NT4, why I suspect it needs to be swappable/discardable.
This driver goes here, that driver mounts there. 2. Implement 2 basic drivers: Wine builtin format, Windows binary format.
I don't know what "Wine builtin format" is, neither do I know how it fits the NT security model. Could you elaborate?
- Enable dynamic load of external drivers.
If this is to be handled as suggested, by a registry branch below wine/wine/config, it means that branch would have to be locked down to only allow administrator write/modify (maybe even read) access. It also opens the door for serious malice, in case a malicious service registers the RPC service before one of the intended services got to do its work, and...
Basically, I urge you to seriously reconsider your proposal while thinking of every aspect you can imagine (and then a few more). I think the intentions are good, and I like the basic ideas, but at the same time I suspect the effort and all the implications might have been underestimated. Especially the security problems.
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.
I assume you know how MS handles this, by downloading a roaming registry from a DC to the local machine? Knowing the unreliability of networks, and other non-local media (compared to local media, even if that fails too) I nowadays have grown to think MS did the right choice in having the hives downloaded to the local machine when logging on.
/Mike