Hi,

I'm working on a multimedia driver DLL, i.e. one that Windows loads on behalf of any program that uses the Windows multimedia API.

I'm using a .def file with an EXPORTS section, and I've also got all the relevant functions marked as 'export' in the code.

What I'm finding is, if I remove the 'export' attribute but keep the EXPORTS section, it all still works; but if I keep the 'export' attribute and remove the EXPORTS section, then it doesn't work.

Just wondering why this is, and whether the 'export' attribute is actually programmed to do anything at the moment :)

Thanks,

Ben :)

Am 09.02.2013 21:35, schrieb Ben Davis:
> Hi,
>
> I'm working on a multimedia driver DLL, i.e. one that Windows loads on
> behalf of any program that uses the Windows multimedia API.
>
> I'm using a .def file with an EXPORTS section, and I've also got all the
> relevant functions marked as 'export' in the code.
>
> What I'm finding is, if I remove the 'export' attribute but keep the
> EXPORTS section, it all still works; but if I keep the 'export'
> attribute and remove the EXPORTS section, then it doesn't work.
>
> Just wondering why this is, and whether the 'export' attribute is
> actually programmed to do anything at the moment :)
>
> Thanks,
>
> Ben :)

Yes it is, but its only working properly for global functions. It works partially for classes and not at all for all remaining cases. The export attribute is currently only usefull if you want to do a C-Style interface for your Dll.

Kind Regards
Benjamin Thaut

On 2/9/13, Ben Davis <entheh@cantab.net> wrote:
> Hi,
>
> I'm working on a multimedia driver DLL, i.e. one that Windows loads on behalf of any program that uses the Windows multimedia API.
>
> I'm using a .def file with an EXPORTS section, and I've also got all the relevant functions marked as 'export' in the code.

Export in code allows you to avoid listing exported functions in the DEF file. However you should likely still use the DEF file even if it lacks a list, as I recall there's a bug related to not using DEF files (I can't find the issue right now).

On 09/02/2013 20:44, Andrej Mitrovic wrote:
> On 2/9/13, Ben Davis <entheh@cantab.net> wrote:
>> Hi,
>>
>> I'm working on a multimedia driver DLL, i.e. one that Windows loads on
>> behalf of any program that uses the Windows multimedia API.
>>
>> I'm using a .def file with an EXPORTS section, and I've also got all the
>> relevant functions marked as 'export' in the code.
>
> Export in code allows you to avoid listing exported functions in the
> DEF file. However you should likely still use the DEF file even if it
> lacks a list, as I recall there's a bug related to not using DEF files
> (I can't find the issue right now).

(Oops, silly Thunderbird)

I know which issue you mean, because I came across it earlier. It's something about needing "EXETYPE NT" and "SUBSYSTEM WINDOWS" or else something bad happens with thread-local storage. I don't think it had anything to do with exports.

What you're telling me (about the purpose of export in code) is what I assumed was the intention, but the fact is it's not behaving that way. If I mark the functions as export in the code, but remove the EXPORTS section from the .def file (but keep the rest of the .def file), then the DLL doesn't work, which suggests that the export table did not contain those functions.

Perhaps the exports in the code only apply if the .def is entirely missing? Is that the desired behaviour? (I won't be trying that, as I know it would break in other ways then.)

Ben :)

On 09/02/2013 20:39, Benjamin Thaut wrote:
> Am 09.02.2013 21:35, schrieb Ben Davis:
>> Hi,
>>
>> I'm working on a multimedia driver DLL, i.e. one that Windows loads on
>> behalf of any program that uses the Windows multimedia API.
>>
>> I'm using a .def file with an EXPORTS section, and I've also got all the
>> relevant functions marked as 'export' in the code.
>>
>> What I'm finding is, if I remove the 'export' attribute but keep the
>> EXPORTS section, it all still works; but if I keep the 'export'
>> attribute and remove the EXPORTS section, then it doesn't work.
>>
>> Just wondering why this is, and whether the 'export' attribute is
>> actually programmed to do anything at the moment :)
>>
>> Thanks,
>>
>> Ben :)
>
> Yes it is, but its only working properly for global functions. It works
> partially for classes and not at all for all remaining cases. The export
> attribute is currently only usefull if you want to do a C-Style
> interface for your Dll.

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

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.

Kind Regards
Benjamin Thaut

-- 
Kind Regards
Benjamin Thaut

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

Am 10.02.2013 13:36, schrieb Ben Davis:
> With the def, I get lines like "DriverProc = _DriverProc@20".
> Without it, I get lines like "_DriverProc@20 = _DriverProc@20".

Then you did hit this 3 year old bug: http://d.puremagic.com/issues/show_bug.cgi?id=3956

On 10/02/2013 12:39, Benjamin Thaut wrote:
> Am 10.02.2013 13:36, schrieb Ben Davis:
>> With the def, I get lines like "DriverProc = _DriverProc@20".
>> Without it, I get lines like "_DriverProc@20 = _DriverProc@20".
>
> Then you did hit this 3 year old bug:
> http://d.puremagic.com/issues/show_bug.cgi?id=3956

I don't think I did.

That bug applies to cases WITHOUT a .def file, and in that bug, the actual vs expected output is:

_DriverProc@mangledinsomeway (correct)
modMessage@mangledinsomeway (should be _modMessage@mangledinsomeway)
midMessage@mangledinsomeway (should be _midMessage@mangledinsomeway)

In my case, when I build without a .def file, I get:

_DriverProc@mangledinsomeway
_modMessage@mangledinsomeway
_midMessage@mangledinsomeway
not what I want, but correct as per the spec (I assume). Which would imply the bug was fixed at some point.

My example of "DriverProc =" (without the _) was WITH a .def file, AND is what I want - there is no bug as far as I'm aware.

For reference, when Andrej mentioned in earlier bug involving not having a .def, I thought of this one: http://www.digitalmars.com/d/archives/digitalmars/D/Windows_DLLs_and_TLS_177871.html

Hope it's clear now?

Ben :)

On 10/02/2013 14:11, Ben Davis wrote:
> Which would imply the bug was fixed at some point.

...though of course it would need verifying with the example actually quoted in the bug, since there may be subtle differences. (Hopefully I'm just stating the obvious.)