For DLLs, what does export actually do?

[Ben Davis]

On 09/02/2013 20:44, Andrej Mitrovic wrote:
> On 2/9/13, Ben Davis <entheh at 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 :)