For DLLs, what does export actually do?

[Regan Heath]

On Sun, 10 Feb 2013 12:36:38 -0000, Ben Davis <entheh at cantab.net> wrote:

> On 10/02/2013 08:17, Benjamin Thaut wrote:
>> Am 10.02.2013 03:03, schrieb Ben Davis:
>>>
>>> My functions are "export extern (Windows)" - I think they're global...?
>>>
>>> For example:
>>>
>>> export extern(Windows) LRESULT DriverProc(DWORD_PTR dwDriverId, HDRVR
>>> hdrvr, UINT msg, LONG lParam1, LONG lParam2) nothrow { ... }
>>
>> Do you have a copy of visual studio around? If so you can use
>> dumpbin /EXPORTS your.dll
>>  From a visual studio command shell to see the symbols the dll actually
>> exports. Just compare the version where you manually listed them in the
>> exports section with the version where you don't manually list exports.
>
> Thanks, that helped expose what's going on.
>
> With the def, I get lines like "DriverProc = _DriverProc at 20".
> Without it, I get lines like "_DriverProc at 20 = _DriverProc at 20".
> So the difference is that the export is done under a slightly mangled  
> name if I only mark it in the code, and I need to use the def file to  
> specify the exact name to export by. I suppose this is only necessary  
> for weird things like driver entry points, and not for normal exported  
> functions.
>
> A bit more Googling reveals that the @n is the number of bytes taken by  
> arguments, and is part of the stdcall == extern(Windows) convention. So  
> Windows is making me use stdcall and then making me throw that  
> information away in the export table. But hey - it wouldn't be the worst  
> thing I've encountered with the Windows API. (._.'|||| :P)

Some more background info:
http://en.wikipedia.org/wiki/Name_mangling

> DllMain is a weird one - it creates all sorts of linker errors if I try  
> it with extern(C) instead of extern(Windows) (which is different from  
> the other methods, which compile fine with extern(C) and then crash at  
> runtime).

extern(C) will change the mangling.. so in this case I guess the linker is  
expecting DllMain but the mangling is incorrect.  I wonder if the compiler  
detects the presence of DllMain and alters the linker line.  DMD has a  
command line option to output the linker command line, maybe see if it  
changes with/without a DllMain in the code perhaps.

> Also it doesn't matter what name I export it by or whether I export it  
> at all. I'm getting the feeling this is what was implied by "The  
> presence of DllMain() is recognized by the compiler". Good to know  
> anyway - I like to keep stuff clean :)

Yep, DllMain isn't a requirement, but if is present should be called by  
the C runtime when the dll is loaded.  You can hook into process  
start/stop and thread attach/detach with dll main.  It's good for thread  
local storage initialisation - for example.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/