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