Unmanaged C++ DLL o tej samej nazwie współistnieją w tym samym procesie

Question

Przy użyciu Visual Studio C++ V10, staram się dowiedzieć, jak zbudować DLL i rozwiązać konflikt nazw plików DLL. Oto szczegóły.

Firma S wysyła produkt o nazwie M.EXE. Załóżmy, że M.EXE jest zainstalowany w \S\BIN\M.EXE. Firma S statycznie łączy się z biblioteką DLL o nazwie U.DLL, która jest instalowana w wersji \S\BIN\U.DLL. U.DLL zawiera kod open source i jest zbudowany z opcjami kompilatora Visual C++ /Zc:wchar_t-, który nie rozpoznaje wchar jako natywnego typu.

Firma C wysyła bibliotekę DLL o nazwie O.DLL i publikuje interfejsy API dla tej biblioteki DLL oraz wysyła bibliotekę importowania dla O.DLL. Załóżmy, że O.DLL jest zainstalowany w \C\BIN\O.DLL. O.DLL statycznie łączy się z biblioteką DLL o nazwie U.DLL, która jest instalowana w wersji \C\BIN\U.DLL. U.DLL jest zbudowany na tym samym kodzie open source, ale jest zbudowany z opcjami kompilatora Visual C++ /Zc:wchar_t, który rozpoznaje wchar_t jako natywny typ.

Idealnie firma C i firma S zgodziłaby się zbudować U.DLL przy użyciu tych samych opcji Visual C++, ale to nie jest możliwe.

M.EXE z firmy S jest rozszerzalny, że mogę stworzyć własną bibliotekę DLL w niezarządzanych C++, nazywają to NODE.DLL że M.EXE wywoła jeśli ustawi wszystko poprawnie. Chciałbym zbudować NODE.DLL tak, że statycznie linki do O.DLL z firmy C. Ale problemem jest to, że raz M.EXE działa, załadował bibliotekę U.DLL z \S\BIN, a symbole z \S\BIN\U.DLL są nieco inne niż te w \C\BIN\U.DLL, ze względu na to, w jaki sposób każda firma zbudowała U.DLL. Tak więc, gdy M.EXE próbuje załadować NODE.DLL, nie powiedzie się, ponieważ gdy NODE.DLL ładuje O.DLL, który potrzebuje U.DLL, symbole potrzebne od \C\BIN\U.DLL nie istnieją, ponieważ system Windows widzi U.DLL jako już załadowany.

Schemat sytuacja przedstawia się następująco:

M.EXE static link to -> \S\BIN\U.DLL 
M.EXE dynamic link to -> NODE.DLL 
NODE.DLL static link to O.DLL 
O.DLL static link to \C\BIN\U.DLL 

efekcie, trzeba zarówno \S\BIN\U.DLL i \C\BIN\U.DLL współistnieć na tym samym miejscu procesu, i M.EXE wykorzysta wersją U.DLL i O.DLL użyciu jego wersja U.DLL.

Należy pamiętać, że nie mam opcji odbudować M.EXE lub O.DLL, aby zmienić sposób ich ładowania U.DLL. Pochodzą od stron trzecich, więc nie można zmienić linkowania statycznego. Nie mam również możliwości użycia LoadLibrary na O.DLL, ponieważ jest to biblioteka C++, dostarczana z biblioteką importu.

wierzę, że manifesty można stosować tak, że kiedy budować NODE.DLL, który jest połączony z O.DLL statycznie, ustawić rzeczy w manifeście NODE.DLL tak że O.DLL ładuje własną kopię U.DLL który jest zainstalowany w \C\BIN\U.DLL. Po prostu nie mogę wymyślić, jak to zrobić. Idealnie nie chciałbym modyfikować manifestu O.DLL, ale jeśli to jedyne rozwiązanie, będę z tym żyć.

Answer 1

Można mieć wiele bibliotek DLL z tego samego pliku w tym samym procesie, ładując jeden lub więcej z nich ścieżek bezwzględnych. To wymaga dynamicznego ładowania biblioteki DLL, ale zachowanie jest poza tym identyczne.

Zamiast łączenia w trakcie procesu kompilacji, musisz std::string moduleName = appPath + "\s\bin\u.dll"; LoadModule(moduleName.c_str()). Ponieważ jest to jednoznaczne, jakie załadowane są biblioteki DLL, pozwala załadować wiele z nich o "tej samej nazwie".

Po załadowaniu modułu można przypisać każdą z niezbędnych funkcji do wskaźników funkcji, a następnie zawijać je lub użyć legalnego, ale mało używanego, syntax of calling functions pointers as normal functions (funcPtr(params)).

Jeśli korzystasz z najnowszej wersji systemu Windows, możesz użyć manifestów DLL, aby wzmocnić wersjonowanie/nazewnictwo w module i spowodować, że EXE załaduje inną bibliotekę DLL niż zwykle. Nie jestem obeznany z tym, jak dokładnie to się stanie, chociaż jest to udokumentowane w MSDN (i prawdopodobnie również tutaj).

Answer 2

Spróbuj użyć funkcji LoadLibrary i GetProcAddress. Będzie to wymagało zrestrukturyzowania twojego kodu, aby wszędzie korzystać ze wskaźników funkcji. Zobacz:

MSDN web page for LoadLibrary

Answer 3

można rozwiązać DLL source programowo w runtiome za pomocą opcji/delayload łącznikową (Linker/input/Delay Załadowane DLL w właściwości projektu VS) wraz z hakiem niestandardowej. W jednym z plików źródłowych musisz zdefiniować i zarejestrować funkcję przechwytywania opóźnienia. W funkcji obsługi powiadomień dliNotePreLoadLibrary funkcji hook, po prostu wywołaj LoadLibrary z jawną ścieżką do żądanej biblioteki DLL, a następnie przekaż HMODULE DLL z powrotem do kodu opóźnienia. Kod opóźnienia rozdzieli zaimportowane funkcje na bibliotekę DLL, którą podasz, niezależnie od tego, czy inna biblioteka DLL o tej samej nazwie została już załadowana do procesu.

Z góry mojej głowy, twój hak będzie wyglądać mniej więcej tak (gdzie MyCustomLoadLibrary należy zastąpić kodem wywołującym LoadLibrary pełną ścieżką do pożądanej biblioteki DLL w przypadku powodującym konflikt lub po prostu niewykwalifikowaną nazwą pliku) :

#include <delayimp.h> 
FARPROC WINAPI MyDliNotifyHook(unsigned dliNotify, PDelayLoadInfo pdli) 
{ 
    if(dliNotify == dliNotePreLoadLibrary) 
    return (FARPROC)MyCustomLoadLibrary(pdli->szDll); 
    return NULL; 
} 
extern "C" PfnDliHook __pfnDliNotifyHook2 = MyDliNotifyHook; 

Answer 4

Masz szczęście, że U.DLL jest Open Source. Będziesz musiał zbudować wersję obsługującą funkcje zarówno dla funkcji /Zc:wchar_t- i /Zc:wchar_t. Pierwsza opcja określa tylko wchar_t- jako unsigned short. Otrzymasz mnóstwo ostrzeżeń linkera dla duplikatów symboli, dla każdej funkcji, która nie ma argumentu wchar_t, ale w przeciwnym razie skończysz z grubszą biblioteką DLL.

Pamiętaj, że jeśli istnieją zmienne globalne lub static przy użyciu wchar_t, będziesz mieć również dwie kopie tych zmiennych. Ale miałbyś taki sam efekt, gdyby w jednym procesie podwoziono dwie kopie U.DLL.