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.
ShacharThe 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.