When building COM DLLs, why should exports like DllGetClassObject
, DllCanUnloadNow
, DllRegisterServer
, DllUnregisterServer
, etc. be marked PRIVATE
in the EXPORTS
section of the associated .DEF
file?
A DLL file has a layout very similar to an .exe file, with one important difference — a DLL file contains an exports table. The exports table contains the name of every function that the DLL exports to other executables.
The winedump tool for interacting with DLL PE files. We can use the winedump command to display information about a PE file. A PE file stores its exported symbols in its export address table. The PE file then stores its export address table in the “export” section of the PE file.
You can use the "-Wl,--kill-at" linker switch to disable name mangling.
The dllexport and dllimport storage-class attributes are Microsoft-specific extensions to the C and C++ languages. You can use them to export and import functions, data, and objects to or from a DLL.
When you build a DLL, the linker automatically creates an import library for the DLL. It contains a list of all the exported functions. You use that import library in another project that uses the DLL.
Specific to COM servers is that those 4 exported functions are always found with GetProcAddress() and you never have an implicit dependency on a COM dll. You always create COM objects with CoCreateInstance(), the COM plumbing takes care of locating the DLL and using GetProcAddress() to find the DllGetClassObject() function. Same story for DllUn/RegisterServer, found by Regsvr32.exe. And DllCanUnloadNow, found by the COM plumbing. You therefore have no need for an import library.
Using PRIVATE ensures that the function doesn't get exported to an import library. With all of them private, you get no import library at all. Nothing goes wrong if you omit it, you just get an extra file from the linker that you'll never use.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With