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

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?

Hope this helps, Best regards, Tom.

Answer 2

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