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

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 Window开发者_如何学编程s\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?

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.

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?

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'.

Some languages that call DLLs have a mechanism to adapt their names according to the calling application bitness.
For example in LabVIEW, the DLL name can be automatically adapted when using one of two patterns:

1. MyDll*.dll will translate on win32 to MyDll32.dll and on win64 to MyDll64.dll.
2. MyDll**.dll will translate on win32 to MyDll.dll and on win64 to MyDll_64.dll (notice the underscore).

So a suggested naming scheme for native DLL, distributed in both 32-bit and 64-bit binary form is: | | win32 | win64 | |:--------- |:--------------|:---------------| | Scheme 1 | MyDll32.dll | MyDll64.dll | | Scheme 2 | MyDll.dll | MyDll_64.dll |

Having different names can be useful if both DLLs must be in the same folder - alongside the application for example.

Note: if you do not need to have different names, I agree with the answer of doug65536. If you install the DLLs in windows system folders (SysWOW64 and System32), you are better off using the same name MyDll.dll for both bitnesses and let Windows do its magic when needed.