Re: Implement RegFlushKey
Mike Hearn wrote:
This implementation is a little inefficient but without using a random access binary db as Windows does (which I am not going to advocate) it's the best we can do.
Ok, I'm going to be flamed for this, but I'm going to go ahead and ask. This is a request to understand, not a suggestion (yet?). Why not use a general purpose DB system? (postgresql, mysql, whatever) After all, the registry is just a tree shaped database. We can do that using standard SQL, and fall back to our current method if a proper DB is not found. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
This is a request to understand, not a suggestion (yet?). Why not use a general purpose DB system? (postgresql, mysql, whatever) After all, the registry is just a tree shaped database. We can do that using standard SQL, and fall back to our current method if a proper DB is not found.
An idea behind current implementation is that everyone can easily fix the things in the case of corruption, which is a weak point of MS Windows. -- Dmitry.
Dmitry Timoshkov wrote:
"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote:
This is a request to understand, not a suggestion (yet?). Why not use a general purpose DB system? (postgresql, mysql, whatever) After all, the registry is just a tree shaped database. We can do that using standard SQL, and fall back to our current method if a proper DB is not found.
An idea behind current implementation is that everyone can easily fix the things in the case of corruption, which is a weak point of MS Windows.
Ok, let's offer that as an option. The other thing is that, as far as I can tell, the database is awfully simple. Two tables - one for keys, one for values. The keys table: key ID, primary key (serial type in PGsql). Key name, varchar (or whatever). Parent key (foreign key to key ID). unique index on key name (if the database support the collation where things are case insensitive, which most databases should). The values table: Key - foreign key to the Key ID in the keys table Value name, varchar. Value type - long int Value data - binary Primary index - key+value name (unique). Alternatively, if you want easier editing of the DB itself, you can split the data into seperate tables - one for strings, one for numbers, and one for everything else. I believe this design is still simple enough for the DB to maintain data integrity even when editing outside of the scope of Wine, which means you can use the standard DB tools to fix it if something goes wrong (may require triggers, which are generally frowned upon these days. Also means that MySQL is out, as it doesn't have these IIRC). What you gain - fast, efficient, Unicode aware manipulation. Data integrity taken care for you. Concurrancy taken care for you. Seems too good to be true, I think. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
What you gain - fast, efficient, Unicode aware manipulation. Data integrity taken care for you. Concurrancy taken care for you. Seems too good to be true, I think.
Yeah, but nothing beats editing a registry file with Emacs (which is a joy to do when, for example, a damn game refuses to re-install because it detects some keys in the registry from its last installation). Going through an UI to do stuff like that would be so Windowish as to not be funny :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Hi, On Sun, Dec 28, 2003 at 11:25:14AM +0100, Lionel Ulmer wrote:
What you gain - fast, efficient, Unicode aware manipulation. Data integrity taken care for you. Concurrancy taken care for you. Seems too good to be true, I think.
Yeah, but nothing beats editing a registry file with Emacs (which is a joy to do when, for example, a damn game refuses to re-install because it detects some keys in the registry from its last installation).
Going through an UI to do stuff like that would be so Windowish as to not be funny :-) Sure, but please keep in mind that currently loading a full Windows registry (or a full Wine registry once we get there) takes lots of time on Wine startup (Wineserver call scheduling), which could most likely be reduced significantly by adopting a compressed format.
I don't really want to advocate a non-transparent registry format, but if that manages to significantly decrease load time, then I'm afraid the benefits are much higher than the disadvantages. Andreas Mohr
On Sun, 2003-12-28 at 10:25, Lionel Ulmer wrote:
Yeah, but nothing beats editing a registry file with Emacs (which is a joy to do when, for example, a damn game refuses to re-install because it detects some keys in the registry from its last installation).
Yeah, that's why I said I wasn't going to advocate it. I edit/view the registry using emacs all the time. Possibly one solution would be to have a binary cache used for loading and on shutdown the wineserver dumps it to the text version. On startup it compares the modification times of the binary and textual versions, and if the text version is newer (because it was edited by hand) it replaces the binary cache with it. That'd be a good compromise I think. Regardless at the moment wine startup time isn't a huge problem, certainly there are more pressing issues (like the lack of a good typelib compiler).
Mike Hearn wrote:
On Sun, 2003-12-28 at 10:25, Lionel Ulmer wrote:
Yeah, but nothing beats editing a registry file with Emacs (which is a joy to do when, for example, a damn game refuses to re-install because it detects some keys in the registry from its last installation).
Yeah, that's why I said I wasn't going to advocate it. I edit/view the registry using emacs all the time.
Possibly one solution would be to have a binary cache used for loading and on shutdown the wineserver dumps it to the text version. On startup it compares the modification times of the binary and textual versions, and if the text version is newer (because it was edited by hand) it replaces the binary cache with it. That'd be a good compromise I think.
Regardless at the moment wine startup time isn't a huge problem, certainly there are more pressing issues (like the lack of a good typelib compiler).
You wouldn't want to throw away the text version anyway, since then it wouldn't be possible to debug your setup in case wine won't boot anymore. I mean: when winecfg is done, you might get a chicken/egg problem if you screwed up your configuration :-).
--- Mike Hearn <mike(a)theoretic.com> wrote:
Regardless at the moment wine startup time isn't a huge problem, certainly there are more pressing issues (like the lack of a good typelib compiler).
I like being able to edit the registry in vi also but if you guys need a fast binary format, Eric Kohl offered to relicense his work on the ReactOS registry as LGPL. Also there are some tools that I know of that can be license LGPL that will let you read/write in the NT binary format. The developer of NT password cracker for Linux has offered to relicense parts of his work as LGPL/GPL if you decide you do want to move to the Windows format. Thanks Steven __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
On Saturday 27 December 2003 09:23 am, Shachar Shemesh wrote:
Mike Hearn wrote:
This implementation is a little inefficient but without using a random access binary db as Windows does (which I am not going to advocate) it's the best we can do.
Ok, I'm going to be flamed for this, but I'm going to go ahead and ask.
This is a request to understand, not a suggestion (yet?). Why not use a general purpose DB system? (postgresql, mysql, whatever) After all, the registry is just a tree shaped database. We can do that using standard SQL, and fall back to our current method if a proper DB is not found.
Shachar
The SQL thing is not an inherently bad idea, but why /not/ implement the NT "hive" format (the random access binary db mentioned above) instead? This might involve some ugly reverse engineering, but I think this would allow registries saved out via Reg{Save,Restore}Key to work.... in fact, doesn't wine already read this format when using a "Windows" installation? Some months ago I tried to run an application I wrote for my employer, which used those API's to import prefabricated chunks of registry stored in this format, but it failed to read them in. I guess this is another "hey, somebody other than me should do a crapload of work" type of post... but I thought I'd mention it to remind everyone that there is a Windows-API-compatibility justification suggesting that approach. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Gregory M. Turner wrote:
On Saturday 27 December 2003 09:23 am, Shachar Shemesh wrote:
Mike Hearn wrote:
This implementation is a little inefficient but without using a random access binary db as Windows does (which I am not going to advocate) it's the best we can do.
Ok, I'm going to be flamed for this, but I'm going to go ahead and ask.
This is a request to understand, not a suggestion (yet?). Why not use a general purpose DB system? (postgresql, mysql, whatever) After all, the registry is just a tree shaped database. We can do that using standard SQL, and fall back to our current method if a proper DB is not found.
Shachar
The SQL thing is not an inherently bad idea, but why /not/ implement the NT "hive" format (the random access binary db mentioned above) instead? This might involve some ugly reverse engineering, but I think this would allow registries saved out via Reg{Save,Restore}Key to work.... in fact, doesn't wine already read this format when using a "Windows" installation? Some months ago I tried to run an application I wrote for my employer, which used those API's to import prefabricated chunks of registry stored in this format, but it failed to read them in.
I guess this is another "hey, somebody other than me should do a crapload of work" type of post... but I thought I'd mention it to remind everyone that there is a Windows-API-compatibility justification suggesting that approach.
First, I would like to mention that having binary compatible registry implementation is not stricly necessary for load/save compatible to Windows. We can do import on load and export on save, for example. There is also the fact that, if I understand correctly, Windows 9x has different registry syntax from Windows NT, and other ugly stuff. If I understood the discussion so far, it boils down to these options: A. Ascii file - bad performance, easy editing. I'm unclear about Unicode support. B. Our own format - difficult editing, may have good performance if we invest LOTS of hard work. Lots of potential bugs and places to go wrong. C. SQL - good performance, jury is still out on ease of editing (in any case - not as easy as A, but I'm not sure how unicode plays in). Requires configuring yet another software component (but we may make that optional). D. Windows compatible - all the down sides of B plus bad performance. Yes, I can defenitely see how D will be our favourite choice. Just so I do not dump work on other people myself, I may not have time for implementing C start to finish, but I can defenitely help a lot. I'm already familiar with PgSQL, for one thing. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
First, I would like to mention that having binary compatible registry implementation is not stricly necessary for load/save compatible to Windows. We can do import on load and export on save, for example. There is also the fact that, if I understand correctly, Windows 9x has different registry syntax from Windows NT, and other ugly stuff. If I understood the discussion so far, it boils down to these options: A. Ascii file - bad performance, easy editing. I'm unclear about Unicode support. B. Our own format - difficult editing, may have good performance if we invest LOTS of hard work. Lots of potential bugs and places to go wrong. C. SQL - good performance, jury is still out on ease of editing (in any case - not as easy as A, but I'm not sure how unicode plays in). Requires configuring yet another software component (but we may make that optional). D. Windows compatible - all the down sides of B plus bad performance.
Yes, I can defenitely see how D will be our favourite choice.
Just so I do not dump work on other people myself, I may not have time for implementing C start to finish, but I can defenitely help a lot. I'm already familiar with PgSQL, for one thing.
Did you discuss berkely db already? MySQL or another database app that requires a server to run wouldn't be a good option I guess, since you wouldn't want to have a seperate server running just to serve some registry keys. I know of applications (subversion for example) that just demand you to put the berkely db source into a db subdir in the src directory. After that, it finds it itself and stuff compiles like a charm. Also, I didn't follow the discussion really, but did you think of something like this: Initially make 1 big ascii file, as is used now. If the file gets bigger than some treshold, let's say 1 meg, use a hashfunction over the keys to split the file into a few new files that will serve as buckets. So, every time a file gets to big, just split it up. In this solution, at least we will be able to reuse much of the current functionality. Only thing we need is a thingy to determin into which bucket (or file) a certain key was hashed... Grtz, Robert
participants (8)
-
Andreas Mohr -
Dmitry Timoshkov -
Gregory M. Turner -
Lionel Ulmer -
Mike Hearn -
Robert van Herk -
Shachar Shemesh -
Steven Edwards