How should I name a native DLL distributed in both 32-bit and 64-bit form?

Question

I have a commercial product that's a DLL (native 32-bit code), and now it's time to build a 64-bit version of it. So when installing on 64-bit Windows, the 32-bit version goes into Windows\SysWOW64, and the 64-bit version goes into... Windows\System32! (I'm biting my tongue here...) Or the DLL(s) can be installed alongside the client application.

What should I name the 64-bit DLL?

Same name as 32-bit: Two files that do the same thing, have the same name, but are totally non-interchangeable. Isn't that a recipe for confusion and support problems?

Different names (e.g. product.dll and product64.dll): Now client applications have to know whether they are running 32-bit or 64-bit in order to reference my DLL, and there are languages where that isn't known until run-time - .NET being just one example. And now all the statically compiled clients have to conditionalize the import declarations: IF target=WIN64 THEN import Blah from "product64.dll" ELSE import Blah from "product.dll" ENDIF

The product contains massive amounts of C code, and a large chunk of C++ - porting it to C# is not an option.

Advice? Suggestions?

Answer 1

I've decided to follow Microsoft on this, who have kept the same names for the DLLs in System32 when they went to 64-bit. On Win7/64, System32\avicap32.dll is a 64-bit DLL!

There is some potential confusion for myself & my customers, having 32-bit and 64-bit DLLs with the same name. However I think it would be worse to have all my customers have to make their code word-width sensitive. Especially the .NET developers, who can often leave their target platform set to 'AnyCPU'.

Answer 2

Client applications do not have to "know" they are 32 bit or 64 bit. The OS automatically loads DLLs from the appropriate location because it is not possible to load a 32 bit DLL into a 64 bit process, and it is not possible to load a 64 bit DLL into a 32 bit process.

If a 32 bit application tries to load something from system32, the OS will silently redirect it to the SysWow64 directory, forcing the 32 bit version to load.

By having different names, you defeat this whole mechanism. A mechanism built specifically to allow you to use the same name.

Answer 3

Why not prefix the dll's with an underscore ... such as product_32.dll and product_64.dll? OR indicated this by using a platform prefix - product_x86_32.dll and product_x86_64.dll? At least that will clear the confusion of the naming of the DLL... What do you think?