1

Our application has up to now only used 32 bit binaries, it was enough. Slowly we see the need to introduce 64bit versions (in addition to the 32 bit version) for some components, mostly for interfacing with other 64bit components that we didn't write ourselves.

One question that popped up was whether we want to name the 64bit components (EXE + DLLs) identically to their 32bit counterparts and put them in a another directory, or whether to name them differently (e.g. tool.exefor 32bit and tool64.exe for 64bit) and leave them in the same directory.

Microsoft has seemingly gone the route of different directories and identical names for most of the Windows components (WoW64), and if the whole application were 64 bit, we'd also have the case to just use the Program Files vs. the Program Files (x86) directory.

However, in our case we have a largely 32bit application that uses some 64bit components (executables) to do 64bit stuff and for some of these we also have a 32bit version that is also used.

So, do we rename components and put them in the same binary directory or do we keep the binary name the same and put it into a subdirectory?

What are the pros and cons?

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • Sure, it is but a simple deployment detail. 64-bit programs go in c:\program files, 32-bit programs go in c:\program files (x86). There isn't any good reason to make it more complicated than that. – Hans Passant Jun 12 '13 at 13:08
  • @Hans - IMHO, splitting a single application, that happens to consist of multiple executable components -- and note that these components are transparent to the user, there's only the 32bit main application that the user actually starts -- splitting these into the PF and the PF(x86) directory doesn't sound like a good idea. Iff the main app were 64bit sure, it'd go to PF instead of PF(x86), but this isn't the case here. – Martin Ba Jun 12 '13 at 20:08

2 Answers2

1

If we're talking about a single application, all of its files should be kept in a single directory, per the bitiness. Meaning, either PF, or PF(x86). But not spread around.

Regarding components, ask yourself this. Are these components used interchangeably, or do are they used in parallel?

If it's one the former, then have them the same name, this will simplify your deployment. But if it's possible that both are used at once, for example, a DLL that is used by both 32-bit process, and your 64-bit helper process, then split the names. Otherwise you will need to split up your directory structure.

Daniel Goldberg
  • 19,908
  • 4
  • 21
  • 29
0

Now I had to link to the 64 bit boost library DLLs.

Boost 64 bit DLLs have the same name as their 32 bit counterparts and there is no built-in way in Boost Build to change the output name, creating additional work if you would want them in the same directory.

Looking around, it seems that e.g. Qt doesn't include any platform or bitness tags in their DLL which would again generate problems if you would need 32bit and 64bit in the same directory.

So, it would seem that if you have 3rd party DLL dependencies in your application, and you need both the 32bit and 64bit application installed at the same time, then, no matter how you name the executable (or your DLL) itself, putting them into different directories seems a good idea because then it's easy to work with 3rd party stuff that doesn't "tag" its DLLs with the bitness, because there really isn't a good way of loading different DLLs with the same name from the same directory (unless you put them into System32 / SysWOW64, which you shouldn't).

Community
  • 1
  • 1
Martin Ba
  • 37,187
  • 33
  • 183
  • 337