6

I'm updating a DLL for a customer and, due to corporate politics - among other things - my company has decided to no longer share source code with the customer.

Previously. I assume they had all the source and imported it as a VC++6 project. Now they will have to link to the pre-compiled DLL. I would imagine, at minimum, that I'll need to distribute the *.lib file with the DLL so that DLL entry-points can be defined. However, do I also need to distribute the header file?

If I can get away with not distributing it, how would the customer go about importing the DLL into their code?

audiFanatic
  • 2,296
  • 8
  • 40
  • 56

4 Answers4

14

Yes, you will need to distribute the header along with your .lib and .dll

Why ?

At least two reasons:

  • because C++ needs to know the return type and arguments of the functions in the library (roughly said, most compilers use name mangling, to map the C++ function signature to the library entry point).
  • because if your library uses classes, the C++ compiler needs to know their layout to generate code in you the library client (e.g. how many bytes to put on the stack for parameter passing).

Additional note: If you're asking this question because you want to hide implementation details from the headers, you could consider the pimpl idiom. But this would require some refactoring of your code and could also have some consequences in terms of performance, so consider it carefully

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Name mangling isn't particularly relevant. You need C headers for precisely the same reason you need C++ headers, even on platforms whose C ABI does not substantively "mangle" C symbols (i.e. not VS). In both cases you _could_ redeclare all the library symbols in your own code, but someone's got to tell you what those symbols are, which... well, that's a header! – Lightness Races in Orbit May 17 '16 at 17:55
6

However, do I also need to distribute the header file?

Yes. Otherwise, your customers will have to manually declare the functions themselves before they can use it. As you can imagine, that will be very error prone and a debugging nightmare.

R Sahu
  • 204,454
  • 14
  • 159
  • 270
3

In addition to what others explained about header/LIB file, here is different perspective.

The customer will anyway be able to reverse-engineer the DLL, with basic tools such as Dependency Walker to find out what system DLLs your DLL is using, what functions being used by your DLL (for example some function from AdvApi32.DLL).

If you want your DLL to be obscured, your DLL must:

  • Load all custom DLLs dynamically (and if not possible, do the next thing anyhow)
  • Call GetProcAddress on all functions you want to call (GetProcessToken from ADVAPI32.DLL for example

This way, at least dependency walker (without tracing) won't be able to find what functions (or DLLs) are being used. You can load the functions of system DLL by ordinal, and not by name so it becomes more difficult to reverse-engineer by text search in DLL.

Debuggers will still be able to debug your DLL (among other tools) and reverse engineer it. You need to find techniques to prevent debugging the DLL. For example, the very basic API is IsDebuggerPresent. Other advanced approaches are available.

Why did I say all this? Well, if you intend to not to deliver header/DLL, the customer will still be able to find exported functions and would use it. You, as a DLL provider, must also provide programming elements with it. If you must hide, then hide it totally.

Ajay
  • 18,086
  • 12
  • 59
  • 105
0

One alternative you could use is to pass only the DLL and make the customer to load it dynamically using LoadLibrary() + GetProcAddress(). Although you still need to let your customer know the signature of the functions in the DLL.

More detailed sample here:

Dynamically load a function from a DLL

Alvaro Palma Aste
  • 381
  • 3
  • 16