For DLLs, what does export actually do?

[Ben Davis]

On 11/02/2013 16:06, Regan Heath wrote:
> On Sun, 10 Feb 2013 12:36:38 -0000, Ben Davis <entheh at cantab.net> wrote:
>> 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.

I think that's exactly what's going on. If it was only the mangling, I'd 
expect one error relating to that function, but instead I get at least 
10 errors relating to various functions I've never heard of. I don't 
think there's any particular need to test further.

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

Yep, sounds about right - and it sounds like something that gets 
resolved in a special way when the DLL is linked. Certainly DllMain 
isn't appearing in my export table, yet I've established (by calling 
MessageBoxA from inside DllMain - that was brave of me, wasn't it? :P) 
that it is being called. :)