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@20".
Without it, I get lines like "_DriverProc@20 = _DriverProc@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 :)
