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

[Mike Hearn]

On Sun, 2005-03-13 at 13:29 +0200, Boaz Harrosh wrote:
> Well! Above logic just eliminated Wine my friends. If Native dlls and 
> Registry is a set back on "Free" Wine development, than logic would 
> follow that, running native Windows applications (Wine) is a set 
> back/discouragement of Free SW development.

I'd agree that being able to use real Windows stuff is useful and
beneficial. I don't personally subscribe to this belief that forcing
people to use stuff magically makes hackers appear, but it's not my call
to make. And nobody ruled out putting the registry loading code back in.

> I'm almost sure my words will change nothing, but I must say them! (And 
> maybe they will)
> 
> Wine development as been following CodeWeavers business plan for a long 
> time, which is more than fine, but this time it broke a statuesque.

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?

>     Not being able to dynamically load a Windows registry. Almost 
> completely eliminates the possibility of a None CodeWeavers (Like) Wine 
> use. Let me explain. 2 examples to use wine None Codeweavers way.

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.

> 1. I have a legal copy of Windows I want to use in Linux (say). Well OK 
> a one time, static transition. Winecfg above could cope with that, 
> unless I want to double boot. There have been more than me users out 
> there that double boot, the same windows installation. There use to be 
> lots of options for control of mix and match. Programs that would not 
> install, but would still be usable, by installing on the Windows side. 

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. 

> Removing Load of Native windows Registry, Breaks the very Logic that 
> Wine stands on. For me it is like saying don't Load PE dlls, use Winlib 
> ones. I mean the support is there guys. You cannot remove it. If current 
> loading order breaks other things you need to do, than fix it. But 
> removing it is not a viable solution. It narrows down the use of Wine to 
> the point of no choice, No alternatives, and no Half baked solutions. 
> Ether it works or it doesn't.

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

thanks -mike