Geek Answers Handbook

Do I need to distribute the header file and the lib file using a DLL?

I am updating the DLL for the client and, thanks to corporate policy, among other things, my company decided not to share the source code with the client anymore.

Before. I assume that they had all the source code and imported as a VC ++ 6 project. Now they will have to connect to the precompiled DLL. I would suggest that, at a minimum, I would need to distribute the *.lib file with the DLL so that the entry points of the DLL could be determined. However, do I also need to distribute the header file?

If I can avoid spreading it, how could the client import the DLL into its code?

+5
source share
3 answers

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 type of the return value and the arguments of the functions in the library (something like this, most compilers use the name mangling to match the signature of the C ++ function to the library entry point).
  • because if your library uses classes, the C ++ compiler must know its layout in order to generate code in your library client (for example, how many bytes to put on the stack to pass parameters).

Note: If you ask this question because you want to hide implementation details from the headers, you can consider pimpl idiom . But this will require some refactoring of your code and may also have some performance implications, so consider it carefully

+12
source

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 them. As you can imagine, this will be a very error prone and debugging nightmare.

+4
source

In addition to what others have explained in the header / LIB file, there is another perspective.

In any case, the client will be able to reconstruct the DLL using basic tools such as Dependency Walker to find out which DLLs your DLL uses, which functions your DLL uses (for example, some functions from AdvApi32.DLL).

If you want your DLL to be hidden , your DLL should:

  • Load all custom DLLs dynamically (and if this is not possible, do the following anyway)
  • GetProcAddress call for all functions that you want to call ( GetProcessToken from ADVAPI32.DLL for example

Thus, at least the dependency host (without tracing) will not be able to find which functions (or DLLs) are used. You can load the functions of the system DLL by sequence numbers rather than by name, so it is more difficult to reverse engineer a text search in a DLL.

Debuggers can still debug your DLL (among other tools) and rebuild it. You need to find methods to prevent DLL debugging. For example, the simplest API is IsDebuggerPresent . Other advanced approaches are available.

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

+2
source

More articles:


All Articles