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

[Boaz Harrosh]

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