DLL对静态库的依赖

Question

I currently build a purely static library MainLib for our customers that contains all symbols so that they can intrgrate it into their program. For several reasons, I now need to deliver a DLL version of MainLib that contains parts of the symbols alongside a static library FeatureLib that contains the remaining symbols. One reason is that we want to avoid bad guys using our software by simply stealing the DLL that is provided via the program of our customer. This wouldn't work if parts of the symbols are integrated within the calling software via a static library . The user of the package shall only be able to use the DLL if he added the symbols of FeatureLib into his application.

For Linux, I can make this work like a charm,ie the symbol doFeature() is not within libMainLib.so , but I don't succeed on this for Windows.

CMakeLists.txt :

cmake_minimum_required(VERSION 3.0)

project(MainLib)

add_library(FeatureLib STATIC src/FeatureLib.c)
target_include_directories(FeatureLib PUBLIC include
                                      PRIVATE src)

add_library(MainLib SHARED src/MainLib.c)
target_include_directories(MainLib PUBLIC include
                                   PRIVATE src)

# I don't want to include symbols from FeatureLib into shared MainLib
#target_link_libraries(MainLib PRIVATE FeatureLib)

add_executable(MainLibDemo src/demo.c)
target_link_libraries(MainLibDemo MainLib FeatureLib) #resolve symbol doFeature()

FeatureLib.h :

extern int doFeature(int input);

MainLib.h :

extern __declspec(dllexport) int MainLib(int input);

FeatureLib.c :

#include "FeatureLib.h"
int doFeature(int input) {return 4;}

MainLib.c :

#include "FeatureLib.h"
#include "MainLib.h"

__declspec(dllexport) int MainLib(int input)
{
  if (input > 2) {
    return doFeature(input);
  } else {
    return doFeature(0);
  }
}

demo.c :

#include <stdio.h>
#include <stdlib.h>

#include "MainLib.h"

int main(int argc, char **argv)
{
  if(argc > 1)
    return MainLib(atoi(argv[1]));
  else
    return 0;
}

With this, I get the following compilation error:

"C:\Daten\tmp\DemoProject\simple\build\ALL_BUILD.vcxproj" (Standardziel) (1) ->
"C:\Daten\tmp\DemoProject\simple\build\MainLib.vcxproj" (Standardziel) (4) ->
(Link Ziel) ->
  MainLib.obj : error LNK2019: unresolved external symbol _doFeature referenced in function _MainLib [C:\Daten\tmp\DemoProject\simple\build\MainLib.vcxproj]
  C:\Daten\tmp\DemoProject\simple\build\Debug\MainLib.dll : fatal error LNK1120: 1 unresolved externals [C:\Daten\tmp\DemoProject\simple\build\MainLib.vcxproj]

    0 Warnung(en)
    2 Fehler

Is this even possible with Windows? What do I have to do to make it work and how can I verify it other than not linking FeatureLib to MainLibDemo . Any ideas are very welcome.

Kind regards, Florian

Answer 1

The way you do it under Linux will not work under Windows because dynamic linking works differently here. Here is one strategy that could work.

In MainLib.dll code, instead of directly calling doFeature you need to define a global pointer variable of proper function pointer type and use it to call the function. This will allow to build MainLib.dll without errors.

Now you need to set this pointer variable. One way would be:

• Add exported function to MainLib.dll that takes pointers to all functions that the DLL needs from the executable.

• In FeatureLib.lib code add an initialisation function that the application will need to call before using your DLL which will pass pointers to its peers to the DLL.

This is basically the way most programs with plugins use to give the plugins access to their facilities.

Another way would be to (Warning! I have not tested this specific solution):

• Declare the functions in FeatureLib.lib as exported with __declspec(dllexport) . This way they will be exported from executable.

• In MainLib.dll before first using the pointers use GetModuleHandle and GetProcAddress to obtain the pointers. It would best be done in some initialisation function for the library. Otherwise you need to take care to avoid race conditions.

Hope this will help. Though I do not think your copy protection scheme will work. Andrew Henle is right in his comment: it is not hard to extract the needed code from one executable and include it in another.