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
pgpJtRZJKkxaE.pgp
Description: PGP signature
