Can you have multiple DLLs with common exports/ordinals and exchange at run-time?-CodePudding

I am trying to create a couple of Win32 64-bit DLLs (Windows 10) which have different implementations but consistent symbol exports. The aim for this is that one would link with whichever one at build time but have the option at deployment to install either DLL and correctly run with that. I have achieved this straightforwardly on Linux where I am much more comfortable and familiar with run-time linking. But on Windows, I have not yet managed this and I am wondering if this is possible at all. I am trying this using both VS2010 and VS2019.

Suppose I have two libraries blah_legacy.dll and blah_modern.dll. They both export 6 symbols which are the interface to using the library, e.g. blah_open, blah_read, blah_write, blah_close, blah_control, blah_status.

I can link with the import library for either blah implementation and a test program calling each symbol loads and executes correctly with the corresponding blah DLL.

However, I cannot yet switch the DLLs at run time. For example, should I actually be able to link with blah-legacy.lib and then run with blah-modern.dll if I rename it to blah-legacy.dll? (Or vice-versa.)

I already got around basic file-naming issues and ensured the DLL needed can actually be found. I still got the application failed to start (0x22).

I used "objdump -xs" on the DLLs and noticed the order of symbols and their ordinals are different. So I created a .def file and ensured that the exported symbols match in number, names and in ordinals. Still nothing - the same error occurs.

There's still something to this I clearly have not figured out and would appreciate some guidance. Is this actually possible? Where do I start to look (which tools) to figure out what step to take next.

CodePudding user response：

Yes.

I don't use Visual Studio much, but this is the kind of thing that happens all the time if you use MSYS2, and install some MinGW packages, and update them.

Here's what I mean by that: MSYS2 is an open source software distribution for Windows that, among other things, provides a bunch of native Windows software packages. The package manager (pacman) let's you choose which packages to have in your system, and it downloads DLLs and EXEs that were created by the MSYS2 developers. When an MSYS2 developer updates a library, you can download the updated library package, and all the other packages using that library will automatically start using the new DLL. Usually there is no issue with that because the new library version will be ABI-compatible with the old library version.

You do not need to use LoadLibrary or otherwise mess up your source code; the linker and the operating system should be able to take care of this for you.

Example

Here is a minimal example I threw together with MSYS2 showing how this can work.

The file foo_legacy.c represents your legacy DLL. I added some extra symbols so it wouldn't be too similar to the modern DLL.

__declspec(dllexport) int eoo() {
  return 0;
}

__declspec(dllexport) const char * foo_name() {
  return "legacy";
}

__declspec(dllexport) int foo_version() {
  return 1;
}

__declspec(dllexport) int goo() {
  return 0;
}

The file foo_modern.c represents the modern implementation:

__declspec(dllexport) const char * foo_name(void);
__declspec(dllexport) int foo_version(void);

int foo_version() {
  return 2;
}

const char * foo_name() {
  return "modern";
}

The file main.c represents an application using the foo API:

#include <stdio.h>

__declspec(dllimport) const char * foo_name(void);
__declspec(dllimport) int foo_version(void);

int main()
{
  printf("%s %d\n", foo_name(), foo_version());
}

My build.sh file is a Bash script that builds and tests everything:

#!/usr/bin/bash
set -uex
gcc -Wall foo_legacy.c -shared -o foo_legacy.dll
gcc -Wall foo_modern.c -shared -o foo_modern.dll
gcc -Wall -c main.c -I. -o main.o
gcc main.o foo_legacy.dll -o main.exe
./main.exe  # output: "legacy 1"
mv foo_modern.dll foo_legacy.dll
./main.exe  # output: "modern 2"
rm foo_legacy.dll
./main.exe  # fails because foo_legacy.dll is not found

The build script runs main.exe three different times, showing that it can either use the legacy DLL, or use the modern DLL, or fail, depending on what was installed in foo_legacy.dll.