wine/ misc/registry.c documentation/samples/config

[Boaz Harrosh]

Mike Hearn wrote:

>Oh for goodness sake, Alexandre already explained that the whole purpose
>of this change was to start on moving the config file into the registry
>so we can use winecfg. You know, winecfg, that program that CodeWeavers
>don't need because we already have our own? That program which I myself
>have helped write?
>
>  
>
Ok I apologize I was a bit harsh. Maybe it is true in the negative 
sense. If it breaks Crossover it can wait.

>You can use a real Windows drive with Crossover, we don't disable it. We
>just don't provide tech support for that configuration (for good
>reasons!). Using a fake windows drive is the default, just like WineHQ.
>
>I'd note that Jeremy White has actually suggested us supporting people
>re-using real Windows drives before because it's sometimes requested by
>customers but that idea was nixed due to extra support costs. So it's
>not like there is some borg-like collective mind at work here saying
>"using native Windows stuff is evil". That's a total fantasy.
>
>  
>
Exactly my point, a business plan view of the code. Off course Crossover 
can do it ("could" in present tense), it is wine. Actually the Hebrew 
App I was talking about, I started my work on Crossover. I did an 
Initial crossover Install, switched to alternative, native directory, 
than Used Crossover to install some stuff. Than switched to Winehq 
Hacked dlls.
If I did not state it clear enough, than please forgive me. I do not say 
any thing is Intentional and/or pre-meditated. I'm just saying it is 
focused, and so it should.

>Given the huge amount of code that's gone into installers lately I'd
>like to think this "use case" will shortly become unnecessary. But yes,
>there will always be at least one installer we cannot run. 
>
>I think we'd do just as well to provide a little tool you can run on
>Windows to watch a software installation and import the registry
>entries/files into Wine. 
>
>  
>
This is where you are wrong my friend. You will never get there. Windows 
is a moving target and Wine is always doomed to follow up. There is a 
constant: "not yet implemented". Thumbs up for the job already done. It 
is incredible.

The tool you propose is not it, as I said in my first post, "Dynamic" is 
the only solution for what I was talking about, i.e. the use of same 
registry.

>OK, so I'd rather this functionality did not have to be dropped, but I
>know *for a fact* that we are asked about winecfg a lot more than using
>Wine with a real Windows setup. Alexandre hasn't ruled out putting it
>back in, so if somebody wants to they can take the code and re-integrate
>it in a way that makes AJ happy (in winecfg or whatever).
>
>  
>
That is because it is the type of people you will not here about.
You must admit that AJ is the most allegeable in making AJ happy. So if 
he removed it, what are the chances I'll make him happy?
If Winecfg breaks such basic functionality, than it is badly designed, 
and should be rethought. I don't want to go into a technical argument 
here. A registry bootstrapping registry is probably a difficult task. 
You need a seed registry that can later in the boot, merge with a bigger 
registry. Hence the use of config file before. On windows I do not have 
control on the registry files used, and I cannot share them with other 
installations. So I guess why Wine should be different. But Wine is 
different, it was different. What is more important? Native registry 
support or No Config file. I would prefer both …

Free Life
Boaz