Implement RegFlushKey

[Shachar Shemesh]

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/