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