There's a bug on bugzilla (422) that asks for the registry file format to be re-written in order to be able to dynamically load parts of the registry. If you don't feel like looking it up - don't worry, I'm going to explain why this would benefit wine. . . It's said that wine loads the entire registry when it first runs, which can get become a waste - even if it's going to be swapped off anyway. . . It's also not the fastest method of input and especially output to the registry. . . I've looked into using a Balanced Tree DB from BerkelyDB as a quicker interface to the registry. . . I think it would be a good solution, but the question is whether or not you want the overhead of another library added to wine. . . That's why I'm writing here actually - I need to know if it's ok to add this dependancy to wine, or if I should find a different approach. I know this would cause some chaos in the community - so If this is something that everyone agrees should be done, I'll write a small utility to convert the current ascii registry files into the new format. . . Let me know what you think . . . --Brad DeMorrow
Brad <syllogism711(a)gmail.com> writes:
There's a bug on bugzilla (422) that asks for the registry file format to be re-written in order to be able to dynamically load parts of the registry. If you don't feel like looking it up - don't worry, I'm going to explain why this would benefit wine. . .
It's said that wine loads the entire registry when it first runs, which can get become a waste - even if it's going to be swapped off anyway. . . It's also not the fastest method of input and especially output to the registry. . .
Actually the current method is probably the fastest for everything except the initial read. Admittedly it's not very elegant, but it's simple and allows us to store everything in text format. So I'm not at all convinced that using a real database would be worth the trouble. -- Alexandre Julliard julliard(a)winehq.org
On Sat, 18 Jun 2005 22:22:56 +0200, Alexandre Julliard wrote:
Actually the current method is probably the fastest for everything except the initial read.
The only reason that the current method is fast is because we're loading the entire registry into memory. As stated in Bugzilla, this is fine for small registries, but the author of the bug has noted wineserver allocated up to 30MB when wine initiates JUST for the registry!
Admittedly it's not very elegant, but it's simple and allows us to store everything in text format.
I'm not saying we should abandon the way we edit our registry - because it is very useful to be able to edit it manually with a text editor. . . HOWEVER, I believe we should have a more elegant way that the API accesses the registry. . Using a small helper app to sync our plain-text registry files into a db format would let us maintain a human-readable format of our registry, while also reducing the overhead required by the current registry format. . .
So I'm not at all convinced that using a real database would be worth the trouble. Using BerkeleyDB to access the registry would provide the kind of random-access that we need for such a large amount of information - It would also provide us with a quicker and easier way to search through the registry - so we could finally implement the Find feature in wine's regedit without much effort ( Not that it couldn't be done as is, but things would definitely be easier ).
I'm really not trying to push something that wouldn't help wine if not now, in the near future. . . A lot of people don't have fast machines with an abundance of memory. . . 30MB can be a lot of memory for someone with 128MB of RAM. . . Please consider this further. . Thanks, --Brad
On Thursday 16 June 2005 11:20 pm, you wrote:
On Sat, 18 Jun 2005 22:22:56 +0200, Alexandre Julliard wrote:
Actually the current method is probably the fastest for everything except the initial read.
The only reason that the current method is fast is because we're loading the entire registry into memory. As stated in Bugzilla, this is fine for small registries, but the author of the bug has noted wineserver allocated up to 30MB when wine initiates JUST for the registry!
How do you propose to keep track of multiple sources of the registry data? At one time Wine supported system-wide registry files as well as per-user ones, and some people would like to see that again.
Using BerkeleyDB to access the registry would provide the kind of random-access that we need for such a large amount of information
Samba already uses something called 'TDB', and it's been suggested that the two projects could share a case-insensitive-filename layer based on it; could you look into using that?
- It would also provide us with a quicker and easier way to search through the registry - so we could finally implement the Find feature in wine's regedit without much effort ( Not that it couldn't be done as is, but things would definitely be easier ).
This could only be done at the expense of several times increase in on-disk storage, and would actually not be used very much. A more useful enhancement would be to support PCRE syntax for find-and-replace, or multiple views of data, or version-control of the registry... in fact, there are Windows programs that do all that, and all they require is a good, stable, quick implementation of the registry calls, which is what Wine provides. -- DLL GPG key at http://www.cse.msu.edu/~lamber45/newmail.htm?GPGkey
David Lee Lambert wrote:
On Thursday 16 June 2005 11:20 pm, you wrote:
On Sat, 18 Jun 2005 22:22:56 +0200, Alexandre Julliard wrote:
Actually the current method is probably the fastest for everything except the initial read.
The only reason that the current method is fast is because we're loading the entire registry into memory. As stated in Bugzilla, this is fine for small registries, but the author of the bug has noted wineserver allocated up to 30MB when wine initiates JUST for the registry!
How do you propose to keep track of multiple sources of the registry data? At one time Wine supported system-wide registry files as well as per-user ones, and some people would like to see that again.
I'm not certain what you mean by multple sources of the registry - but if you're clearifying yourself with your second sentence here, I'm sure it I could bring back that feature if I get the opportunity to and allow system registry files as well as user registry files.
Using BerkeleyDB to access the registry would provide the kind of random-access that we need for such a large amount of information
Samba already uses something called 'TDB', and it's been suggested that the two projects could share a case-insensitive-filename layer based on it; could you look into using that?
I've not heard of this 'TDB' before, nor do I know anything about that situation, however, again - given the opportunity - I will look into whatever the community wants before I make any decisions about how the project will be done.
- It would also provide us with a quicker and easier way to search through the registry - so we could finally implement the Find feature in wine's regedit without much effort ( Not that it couldn't be done as is, but things would definitely be easier ).
This could only be done at the expense of several times increase in on-disk storage, and would actually not be used very much.
I'm not certain you're correct there, and I've been frustrated before when wine's regedit has that menu item disabled when I wanted to use it lol :) At any rate, again, I'm not saying one way or the other about how this is going to work yet (if at all). I'll look into it.
A more useful enhancement would be to support PCRE syntax for find-and-replace, or multiple views of data, or version-control of the registry... in fact, there are Windows programs that do all that, and all they require is a good, stable, quick implementation of the registry calls, which is what Wine provides.
I agree with you there, that would be a nice feature to have - especially if the registry goes binary. . . I'm sure there are some people that would normally use techniques like that with their current registry files. . . Again, however, I'm not doing anything except research until Alexandre gives me the 'go ahead'. Thanks everyone who has been throwing out ideas, they're helpful and extremely appreciated. --Brad DeMorrow
--On Saturday, June 18, 2005 8:31 AM -0400 Brad DeMorrow <syllogism711(a)gmail.com> wrote:
Samba already uses something called 'TDB', and it's been suggested that the two projects could share a case-insensitive-filename layer based on it; could you look into using that?
I've not heard of this 'TDB' before, nor do I know anything about that situation, however, again - given the opportunity - I will look into whatever the community wants before I make any decisions about how the project will be done.
Today's Samba announcement includes something about the ability to handle NT registry files: <http://us2.samba.org/samba/ftp/pre/WHATSNEW-3-0-20pre1.txt>
participants (5)
-
Alexandre Julliard -
Brad -
Brad DeMorrow
-
David Lee Lambert -
Kenneth Porter