CODEWITHSUNDEEP
windowsdllbin
Manuzor
Manuzor

Reputation: 1826

Prevent incompatibilities by choosing distinct names for binaries

You often see that developers have a "bin32" and "bin64" output folder for their software projects, and within these folders live the built executable files, usually called <project_name>.exe and something like <project_name>_d.exe for debug builds. It seemed kind of strange to me, so I began to wonder if there is any reason to name your 32 and 64 bit binaries the same for release and debug builds, only separating them by placing them in different folders.

The following quote, taken from this msdn page, concerns me:

If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.

Assume I have a project called X in 32 and 64 bit builds. While running the 32 bit version of X.exe, which uses X_core.dll in 32 bit, I start the 64 bit version of X.exe. According to the msdn article above, the system tries to execute the 64 bit version of X.exe dynamically linking to the 32 bit version of X_core.dll.

It seems kind of odd and dangerous to me to simply compare dlls by name. Isn't this a good reason to name binaries more distinctly, like <project_name>32.dll, <project_name>64.dll for release builds and <project_name>_d32.dll, <project_name>_d64.dll for debug builds?

Note: I do understand why one would name their debug builds differently than their release builds. Mainly, I would just like to know why it is so common to separate 32 and 64 bit builds, but not debug and release builds.

Upvotes: 0

Views: 25

Answers (1)

Remy Lebeau
Remy Lebeau

Reputation: 595742

A 64bit process cannot load a 32bit DLL, and vice versa. In the MSDN article you linked to, the "memory" it is referring to is the "calling process's memory". A process can load only one instance of a compatible (same bitness) DLL module at a time.

Upvotes: 1

Related Questions