Re: wine/ misc/registry.c documentation/samples/config
Hi, --- Mike McCormack <mike(a)codeweavers.com> wrote:
People would moan and complain, but in the end Wine and Wine users would be better off, as they would no longer depend on anything but Wine to run their Windows software.
I have to agree. Short term being able to load the Windows registry and Windows system dlls helped Wine but long term it has led to stagnation. Most of the recent growth in Wine in past few years has been because we are being forced to not be dependant on a existing Windows install or Windows componates such as DCOM IE, MSI, etc which is a good thing. Thanks Steven __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs
On Sat, 12 Mar 2005 10:35:36 -0800, Steven Edwards wrote:
I have to agree. Short term being able to load the Windows registry and Windows system dlls helped Wine but long term it has led to stagnation. Most of the recent growth in Wine in past few years has been because we are being forced to not be dependant on a existing Windows install or Windows componates such as DCOM IE, MSI, etc which is a good thing.
I'd have to disagree. I am not really convinced this sort of encouragement works: - We have no config file, yet this has apparently not accelerated the pace of winecfg development, we just have more confused users - Systray patch is being kept out of CVS until it's perfect, but nobody except me has hacked on it for years. There are other examples. Citing stuff like DCOM is misleading, that isn't the sort of thing somebody does to scratch an itch. It's been (and still is) a huge project. It's also somewhat orthogonal to being able to use a real Windows drive. thanks -mike
On Sat, Mar 12, 2005 at 06:51:04PM +0000, Mike Hearn wrote:
- We have no config file, yet this has apparently not accelerated the pace of winecfg development, we just have more confused users
AFAIK, winecfg is not working with the real registry stuff, so how would not having a config file accelerate it's development? Let's turn winecfg on, then pass judgement on it. -- Dimi.
Mike Hearn <mike(a)navi.cx> writes:
I'd have to disagree. I am not really convinced this sort of encouragement works:
- We have no config file, yet this has apparently not accelerated the pace of winecfg development, we just have more confused users
Actually there has been quite a bit of work done on winecfg. To get more done requires people to start depending on it, which means finishing the transition to the new config. And in order to do this we need to get rid of the current registry hacks, the first of which is the Windows registry loading code. Whether or not someone works on a replacement is really secondary, the primary goal is to get the new registry stuff in place, even if that means some less used features have to be dropped for the time being. -- Alexandre Julliard julliard(a)winehq.org
On Sat, 2005-03-12 at 21:57 +0100, Alexandre Julliard wrote:
And in order to do this we need to get rid of the current registry hacks, the first of which is the Windows registry loading code.
Ah OK, I didn't realise this was necessary for winecfg to be activated. thanks -mike
Steven Edwards wrote:
I have to agree. Short term being able to load the Windows registry and Windows system dlls helped Wine but long term it has led to stagnation. Most of the recent growth in Wine in past few years has been because we are being forced to not be dependant on a existing Windows install or Windows componates such as DCOM IE, MSI, etc which is a good thing.
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'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. 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. 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. One good example is MSDEV 6, and many others. Hell have you ever tried a "fake drive" Samba mounted on a live XP System. It works and after the Installation/configuration is resolved it is even very stable. 2. A Win4Lin type Wine installation. - Imagine I take ReactOS kernel and mix it in with Wineserver. (OK if I did such a Hack I can probably also return the Windows registry loading code) This gives me an almost complete Windows compatibility on Linux. Well in small term it is done today, many times. I had this Hebrew application that absolutely refused to work on wine. But with combination of method one and down right short circuit some API's I was able to run it on all Native dlls but the Holy Grail. For the sake of this program it was a complete WinXP. Just the way Win4Lin applications see a native Win95. My solution was only good for the App at hand. But it could be better generalized. 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. "The above function has no use in CrossOver, so remove it, if it breaks my head" People! who am I to talk. My Wine Installation is 7 month old. And my wine Hacking is back to nights and weekends. But Philosophically my message is sound. Don't agree with the messenger Just listen to his message. Free Life Boaz
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 restrained myself from saying that many times before, but I guess it should be said: Crippling functionality to get more developers is a tactic guaranteed to backfire. Often the reason new developers get involved is that they need to make something run in Wine for a commercial entity, and Wine already does everything except some small parts that can be developed in a reasonable time. That's like hhctrl.ocx stub was born (which is just a stub, but at least it makes some applications run without the Microsoft DLL), and that's how I got inspired to start a RICHEDIT clone. Had it not run the application I needed with a minimal set of native dlls, I'd have never have motivation to look at the source code of Wine. Removing functionality, even half-baked one, turns those missing small parts into large parts, effectively making Wine useless for those developers-to-be. On the other hand, with enough interest, the half-baked functionality may get improved for reasons like better compatibility or the ability to use the application without Microsoft DLLs (which may be particularly important for people wanting to use Wine with custom applications, in a commercial setting).
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.
No choice, no alternatives, no half baked solutions, no ability to use Wine, no interest in helping the Wine team. Amen. Krzysztof
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
Mike Hearn wrote:
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.
I wrote such a tool once. Do you want me to ask my former employer if he would mind releasing it? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
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
On Sun, 2005-03-13 at 16:31 +0200, Boaz Harrosh wrote:
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.
Hmm, I don't see why. You realise we can't write to the native registry yes? So using a native registry with the old code was equivalent to doing an import each time you started Wine. For the case where you install under Windows then run under Wine, you only need one import anyway. For cases where you change settings under Windows and expect them to be reflected in Wine but not vice-versa, then yes you'd have to use winecfg to reimport each time (but this is functionally equivalent and could be easily shell scripted).
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.
Well exactly. It was removed for technical reasons to do with the switch to a single registry, not winecfg per se.
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 …
We could probably use an environment variable, or auto-detect it in future. thanks -mike
Mike Hearn wrote:
Hmm, I don't see why. You realise we can't write to the native registry yes? So using a native registry with the old code was equivalent to doing an import each time you started Wine. For the case where you install under Windows then run under Wine, you only need one import anyway. For cases where you change settings under Windows and expect them to be reflected in Wine but not vice-versa, then yes you'd have to use winecfg to reimport each time (but this is functionally equivalent and could be easily shell scripted).
The read only was a shortcoming, I did have a script in place that takes user changed keys from wine registry and integrates them back to main registry, on exit. I can't remember if it was you or someone else on the list who suggested this and I followed. What you propose is an order of a magnitude more CPU intensive, and when it hurts the most, on load time. Before I had a script run in the background after the user has left. The work was on a small Wine registry. Now you suggest work on a big Windows registry on load time of an application.
We could probably use an environment variable, or auto-detect it in future.
Why not just map it directly into wine/wine/config: All the old config keys can be supported. Primary file is loaded in two stages. The default wine's system.reg is opened than if a LoadWindowsRegistryFiles is specified that registry is loaded in place, that is, merged into the existing registry. Other secondary files load in the same logic as before as stated by the wine/wine/config keys. Winecfg at bootstrap (Installation) has a Windows-Less system.reg and boots fine. If we want to put up a GUI to configure these settings than a notice Just pops up that states that changes will take effect only after restart of Wineserver. But the GUI is not necessary. Just open system.reg text file and edit a couple of keys, just like config file before. If no one is working on this I could. Just let's agree on the final result. I never understood the difficulty. We used to have a config file, than we opened up and loaded a registry file. And than we would map config file values into the live registry. Now we load up a Primary registry then optionally Map a second registry file into it. It is even simpler than before.
thanks -mike
Thanks Free Life Boaz
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'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.
You're very quick to accuse. This is a techical list and we are technical people, so let's have a technical discussion about the benefits to Wine of the change, rather than a mud-slinging, name calling flame fest, OK? Firstly, the reason that the ability to specify a registry to load in the config file was removed, if I understand correctly, is that if there's no config file, then there's no place so specify a place to load the registry from. There's only going to be a Wine registry, no config file, so the registry location will be fixed. Secondly, Steven and I have stated that we believe that Wine would be better served without the ability to load the registry from an existing windows install. Mike Hearn disagreed with me, and Alexandre likely disagrees too. Thirdly, the description of Wine, from the front page of www.winehq.org is "Wine does not require Microsoft Windows, as it is a completely free alternative implementation of the Windows API consisting of 100% non-Microsoft code, however Wine can optionally use native Windows DLLs if they are available." There's nothing about Win4Lin like functionality in there. I believe we can better write software that works as a 100% non-Microsoft implementation by encouraging people to install software into Wine, report bugs, and use all builtin dlls where possible. Feel free to disagree with me, but argue a technical argument, not an emotive political one. Mike
Mike McCormack wrote:
You're very quick to accuse.
This is a techical list and we are technical people, so let's have a technical discussion about the benefits to Wine of the change, rather than a mud-slinging, name calling flame fest, OK?
I take every thing I said back. I meant in a technical focus sense. It was not clear, and You are right in being offended. Please every body who felt on the other side, forgive me!
Thirdly, the description of Wine, from the front page of www.winehq.org is "Wine does not require Microsoft Windows, as it is a completely free alternative implementation of the Windows API consisting of 100% non-Microsoft code, however Wine can optionally use native Windows DLLs if they are available." There's nothing about Win4Lin like functionality in there.
Until recently it was also "and Optionally use native registry".
Mike
participants (8)
-
Alexandre Julliard -
Boaz Harrosh -
Dimitrie O. Paun -
Krzysztof Foltman -
Mike Hearn -
Mike McCormack -
Shachar Shemesh -
Steven Edwards