Hi List!
The current way we handle Win32 DLL export of symbols is a bit odd in my eyes.
You'll have to add the symbol name to a .def file. If it is a variable, in addition to this you'll need to append DATA to this entry and add WS_VAR_IMPORT to the corresponding header file.
A cleaner way seems to be using the __declspec(dllimport / dllexport) definitions "the right way", as MS itself promotes it e.g. in: http://msdn2.microsoft.com/fr-fr/library/8fskxacy(VS.71).aspx
The "trick" is to add something like:
#ifdef _EXPORTING
#define WS_SYMBOL_IMEXPORT __declspec(dllexport)
#else
#define WS_SYMBOL_IMEXPORT __declspec(dllimport)
#endif
to config.h.win32 - as _EXPORTING is automatically set by the compiler - and a corresponding dummy entry "#define WS_SYMBOL_IMEXPORT" to the automake config file so we dont get compiler errors on UNIX builds.
This way you'll simply add WS_SYMBOL_IMEXPORT to the header file to im/export a symbol, e.g.:
WS_SYMBOL_IMEXPORT int eth_stdio_open (...
... and your done! Ive tried this successfully with function names, DATA symbols should also work the same way.
This has several advantages over the current solution:
- no need for seperate .def files
- no need to add things at two places for a DATA symbol (often forgotten)
- easily rename / delete functions without worrying about the .def file
Any objections against this (in my eyes cleaner) solution?
Regards, ULFL
P.S: A better name than WS_SYMBOL_IMEXPORT would be nice, any ideas? Or is it ok?
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
