"Dimitrie O. Paun" dimi@intelliware.ca writes:
But you see, the interface to the DLL may be small enough that LoadLibrary would do just fine, but most of the time the DLL itself will need registry support, and so on, and so forth.
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.
If the dll does require a lot of Windows features then yes you should use Wine, but then I think it's reasonable to build a Winelib app. Even if we somehow change the linking process so that you can simply add -lwine, you will still end up with a Winelib app, and have to deal with everything this implies. And frankly at that point the exact command line you have to use to link is a minor detail.
The problem with saying that one should be able to use Wine simply by adding -lwine is that "use Wine" means something different for each case. And what people really want is that -lwine should allow them to use the APIs their specific case needs, and not bother them with any other part of Wine; so there's simply no way to offer a general solution for that.