For DLLs, what does export actually do?

[Ben Davis]

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)

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). 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 :)