"Dimitrie O. Paun" dpaun@rogers.com writes:
Moreover, the problem is that in Windows even codecs or SANE driver, or what have you end up needing GUI support, registry, etc. You may think you don't need any of that stuff, and start copying code, and slowly but surely you go down a very dangerous path, and before you know it you end up copying most of Wine.
Even if you need some GUI support, or some registry calls, you most likely don't want to use the Wine variant of them. You want to add stubs to make the calls integrate with your apps; you want controls drawn by the dll to look like your other controls, you want settings to be stored in your app config file not in some mysterious system.reg file, you don't want paths to contain drive letters, etc.
Even if you may end up implementing a whole bunch of Windows functionality, IMO you will implement it in a completely different way.
My hope is that we can lazily initialize enough things such that it's feasible to build a Winelib app even for the simplest things. But that requires that (1) building Winelib apps is easy, and (2) if you don't use expensive features, you don't pay for them.
I don't think that's feasible, at least not without a major change in our development philosophy, which IMO would impact binary compatibility. If you want a lightweight environment, and good Unix integration, what you want is to write a wrapper as thin as possible, that calls to Unix immediately. For instance an open file dialog should resolve to a Qt or Gtk dialog. In Wine we want just the opposite: we want high level features to use the low level features, and call to Unix as late as possible. So the open file dialog calls comctl32, which calls user32, which calls x11drv, which calls the registry, which calls the server; and you end up pulling in most of Wine for what seems to be a trivial function.
The fact is that Wine is a large, mostly self-contained environment, and this is not going to change even if you disguise it as a normal Unix library. And the problem if you do that is that people will expect it to behave like any other library, and it simply won't.
Sure, it would be nice to have a set of small independent modules that you can mix and match with your app to get just the amount of Windows functionality that you require. But IMO that's a different project.