wine/ misc/registry.c documentation/samples/config
boaz at hishome.net
Sun Mar 13 05:29:45 CST 2005
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
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.
More information about the wine-devel