Taking a different tack on the question --- WHY?
…
Either you have the 32-bit version of the game or the 64-bit version of the game.
Slow down there Nelly.
I maintain both 32- and 64- bit versions of my engine, games I make on it, and all its tools, and I really have had 0 issues; I randomly switch day-by-day or whenever I really feel like it between 32-bit and 64-bit as a means of testing and maintaining them.
While I have enough experience to handle both platforms smoothly, at least I can say a simple strategy such as this really helps, and overall I don’t see it quite as troublesome as you make it to sound even for a moderate beginner (though I concede that alignment and range issues will definitely trick up the less-experienced) with some experience on both platforms. It’s really a breeze once you get used to properly using UINT_PTR (or similar on your platform-of-choice), always considering proper use of ranges (which mostly boils down to simply using matching types—don’t use int when .size() returns size_t), and using size-specific types (never use built-in types directly unless following the previous rule about matching types; always use typedefs that specifically enforce the number of bits and the signs of types). The best way to get used to this way of thinking is to actually maintain a project in both 32- and 64- bit builds.
Even if a client only gets one or the other, that means you still need to maintain both, because if you have more than one client you may still need to ship more than one build. Even if it is troublesome to maintain, it’s still necessary.
And these days it is common to need both a 32-bit and a 64-bit build, with 32-bit iOS and Android (native) devices still a prominent marketplace, and 32-bit versions of Windows taking a large share of your audience in Asia. When you update your graphics or sound drivers, they definitely have both 32- and 64- bit versions, and for a reason.
As for needing things loaded dynamically, I agree that this is probably just stupid if the 3rd-party DLL’s are really exclusively 32-bit (he or she needs to clarify). My impression is that he wants them in different directories because one set is all 32-bit and the other set is 64-bit, but he doesn’t want to change their names to avoid run-time hassle in calling LoadLibraryW() (you do call the Unicode function, right? It’s fairly useless otherwise).
He or she needs to be more clear on what he or she is attempting to do, but my advice would be to do what he or she is already doing with his or her DLL’s: Name them accordingly (postfix “x64”) and in your executable build just use a macro and add “x64” to the file name when loading in 64-bit builds.
Otherwise, the 3rd-party DLL’s he or she listed in his or her first post are all static-link-enabled.
Frankly I don’t see the purpose in using DLL’s at all. Why not just static-link to them and save yourself build hassle and the run-time hassle of LoadLibraryW()?
L. Spiro
