CODEWITHSUNDEEP
c++windowsdll32bit-64bit
OffByOne
OffByOne

Reputation: 37

Windows: Building both 32-bit and 64-bit versions of the same DLL

As part of my training for my new contract position, I have been tasked with building two DLLs and two cppunit Unit Test programs. Everything built successfully.

When I tried to run one of the Unit Test programs, I discovered that both of the DLLs (which are used by the Unit Test programs) have mixed 32-bit and 64-bit elements. I downloaded Dependency Walker (Depends.exe) and trace the issue where the DLLs were getting their inputs. 32-bit libraries are in a directory called C:\AppName\bin and 64-bit libraries are in C:\AppName\bin64.

Since DLLS are not loaded until run-time (actually load time) and since DLLs that are not in the same directory as the .exe, and since PATH shows the search order for those two folders as "C:\AppName\bin64;C:\AppName\bin;", when I tried to run the Unit Test, I got an error telling me that there were 64-bit modules mixed in with 32-bit modules, and refused to run. I fixed this issue by renaming bin64 to SAVE_bin64, so that the loader would be unable to find it, default to the other directory, and load the correct DLLs.

My office mate received the same task. He had no such difficulties. Not only that, but I had previously gotten the program to run successfully, but encountered the issue after I had installed some modules using the corporate installation facility. Since the installations occurred in the background, I had no idea what it did, other than foo-barring my builds.

Something in the Visual Studio C++ (unmanaged) build process had included sufficient information into the .exe to let the loader know where to find the correct DLL, but got bollixed up when I did the install.

I did extensive research on this issue before finally discovering the cause by turning on "Full Paths" in Depends.exe, so I have already learned about SxS (Side-by-Side) and DLL Redirection, neither of which is relevant here.

So, the question is, how did the Windows loader find the correct DLLs one time, but not another; how did the loader find the correct DLLs on his machine, but not mine?

Thanks in advance.

Edited to add:

I tried one more experiment. With my bin64 still renamed to SAVE_bin64, I built both libraries (libB.dll is dependent on libA.dll) and the Unit Test programs (both dependent on libB.dll) as 32-bit. Then I renamed SAVE_bin64 back to bin64, so that if the loader is completely dependent on the PATH variable for locating dependent DLLs, the Unit Test program should fail to run, due to 32/64-bit mismatches. However, the Unit Test program ran, successfully finding one error out of 72 modules.

This demonstrates that the Visual Studio 2010 C++ compiler/linker was somehow able to embed the proper locations for dependent DLLs into the executable program, so that the loader did not have to rely on the PATH variable to find the DLLs.

Upvotes: 0

Views: 2577

Answers (1)

mcoill
mcoill

Reputation: 41

This might be helpful in understanding how Windows searches for a dll:
MSDN: Dynamic-Link Library Search Order

The loader will choose whatever dll it sees first (in the search list) that has a matching name. it doesn't matter if the DLL is 64 or 32 bit. I am fairly certain it will even try to load it if it is a text file renamed to .dll Perhaps your co-worker had his dlls in the system folders or side-by-side with the app versions.

I find an easy way to deal with this is to have different names for the dll for 32 and 64 bit. example32.dll and example64.dll.

Upvotes: 1

Related Questions