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