On Sun, 10 Feb 2013 12:36:38 -0000, Ben Davis <ent...@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@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)
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/
