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

Krzysztof Foltman kfoltman at
Sun Mar 13 06:06:03 CST 2005

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.


More information about the wine-devel mailing list