"Kevin Atkinson" <[EMAIL PROTECTED]> wrote: > That is a heck of a lot of work to link with a DLL that is not compiled > with an exports table.
I don't understand you. If a DLL exports something (i.e. has a not zero export directory in the PE header), then it definitely has an export table. > Furthermore, when I use an exports table (ie compile with /def in VC++) > mingw has problems linking with the DLL. It could be that I need to pass > in special options. Simply including the ".lib" file as a link object is > not enough. MinGW (or rather Windows ld port) has its own heuristics for resolving symbols in external libraries. So, just stick to rules and read its documentation. I have an old dllhelpers-0.2.6.tar.gz addon for MinGW with samples how to use DLLs with MinGW, you could find something similar on the net. I'd say that the key of your problems is a bug in MS linker which exports decorated API names. That's similar to an attempt to link against a DLL with C++ style decorated exports created by a compiler from another vendor. > It seams rather strange that wine has so much problems linking with a DLL > not compiled with an exports table. Am I the first one who attempted > this. Probably. Don't forget: Wine is alpha software. Every your contribution makes it better, as it has become much better with the help of many other people. -- Dmitry.