On April 14, 2003 05:27 pm, Alexandre Julliard wrote:
Of course that depends on what the dll does. But for the common case of things like codecs, you don't want to drag Wine into it. Even if the dll is calling a bunch of API functions, you want to stub these to do whatever makes sense for your app; you don't want to have to provide a config file, DOS drives, registry files, the wineserver, the X11 driver, etc. etc.
Stubbing stuff out, and copy&pasting bits of Wine code may be a bit extreme. Yes, it will give the best performance, but it's very inconvenient, and it's very hard to do. I would hope that we can make Wine good enough that linking with it will not require most users to go to that extent.
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.
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.
So let's see what we can do for the examples you give above: - provide a config file: should be merged into the registry soon - DOS drives, registry files: we should have good enough defaults to be able to startup and operate without a registry - X11 driver: lazy load, if apps don't access graphical stuff, there's no need to even initialize this bugger - wineserver: that's the tricky one. I'm not sure lazy initialization would do anything here, but in the future we may provide a dummy version of sorts where the Winelib user knows there is only one process to worry about. Maybe even start it automatically only if there are more than one process to worry about :)
Hey, I don't know how feasible this ideas are, but it's probably worth it to try to make Winelib more easily useable as a library rather than encourage people to hack some bits out of it. I think many of the changes are beneficial to Wine in any event. That's why I think tasking out a long time goal may be a good thing as some of the tasks may bubble out anyway (like the configuration work around winecfg).