🔒 Locked

Windows: 32-bit and 64-bit in harmony

Started by rneckelmann Aug 19, 2010 at 2:05 PM 9 replies 2.6k views

Original Post

Aug 19, 2010 at 2:05 PM

Currently I'm trying to make my personal game frameworks and libraries behave properly on both 32-bit (x86) and 64-bit (x64) Windows.

The actual cross-platformness is no problem for me, I got loads of experience in making my code run on both Windows, Linux, macs, and various toasters. My problem is more like trying to figure out how applications on Windows are expected to behave when it comes to 32-bit vs 64-bit.

My current procedure is:

In Visual Studio 2008 I got a "Win32" configuration and an "x64" configuration. The first one produces executables postfixed with a "32", while the latter uses a "64" postfix instead. For example: MyApp32.exe, MyApp64.exe, MyCoolLibrary32.dll, MyCoolLibrary64.dll, etc. Finally I produce a small x86 EXE-file called MyApp.exe which detects whether it's running under WoW64 (the x86 on x64 "emulation" layer on Windows) and runs MyApp64.exe if it's the case and MyApp32.exe otherwise.

It works perfectly for me, but I suspect it is not how I'm supposed to do it. :P

My main headache at the moment is with 3rd party libraries. I find it a huge mess to manage two different versions of each. For simpler libraries (like libjpeg, libpng, zlib, freetype, etc) I can get away with just linking with them statically. But for monsters like OpenSSL (which I'm fighting atm) it's a complete mess. Not to mention LGPL-licensed libraries which require that you link dynamically.

Now for my questions which I hope someone can enlighten me about:

1) Are applications expected to make seperate releases for x86 and x64? Or should it simply be up to the installer to install the right EXEs and DLLs? I prefer that the user don't have to worry about whether he/she is running 64-bit or not.

2) Can I somehow use .manifest files to make sure that my application links with the appropriate DLLs? I've never managed to understand exactly how manifests are used. If someone can direct me to "manifest files for dummies" I'd be very happy.

Sneftel

Aug 19, 2010 at 3:19 PM

Quote:
Original post by rneckelmann
1) Are applications expected to make seperate releases for x86 and x64? Or should it simply be up to the installer to install the right EXEs and DLLs? I prefer that the user don't have to worry about whether he/she is running 64-bit or not.

For downloadables, it seems to be more common to have separate releases. Not sure about hard copy distribution... I would suggest simply having both versions available in the installer and having the current architecture selected by default, but that's just off the cuff.

Quote:
2) Can I somehow use .manifest files to make sure that my application links with the appropriate DLLs? I've never managed to understand exactly how manifests are used. If someone can direct me to "manifest files for dummies" I'd be very happy.

Sure, that's one of the useful things manifests are for, and it happens without you having to do much extra. I remember there was a great MSDN blog post about manifests, but I can't find it at the moment. Basically, you install your DLLs as side-by-side (SxS) assemblies, without any explicit x86/x64 naming; instead, they have their own directories. The manifest for your application will automatically instruct the system to give it specifically the version which is for your architecture.

cache_hit

Aug 20, 2010 at 12:42 AM

Quote:
Original post by Sneftel
Quote:
Original post by rneckelmann
1) Are applications expected to make seperate releases for x86 and x64? Or should it simply be up to the installer to install the right EXEs and DLLs? I prefer that the user don't have to worry about whether he/she is running 64-bit or not.
For downloadables, it seems to be more common to have separate releases. Not sure about hard copy distribution... I would suggest simply having both versions available in the installer and having the current architecture selected by default, but that's just off the cuff.

Quote:
2) Can I somehow use .manifest files to make sure that my application links with the appropriate DLLs? I've never managed to understand exactly how manifests are used. If someone can direct me to "manifest files for dummies" I'd be very happy.

Sure, that's one of the useful things manifests are for, and it happens without you having to do much extra. I remember there was a great MSDN blog post about manifests, but I can't find it at the moment. Basically, you install your DLLs as side-by-side (SxS) assemblies, without any explicit x86/x64 naming; instead, they have their own directories. The manifest for your application will automatically instruct the system to give it specifically the version which is for your architecture.

Why not just only install the version of the assembly appropriate for the platform in question? If installing on a 64-bit system, only install the 64-bit assembly. I'm not sure I understand what problem the OP is trying to solve, because there is actually no problem. If you're on a 64-bit system, install all the 64-bit DLLs and EXEs that you compiled. If you're on a 32-bit system, install all the 32-bit DLLs and EXEs. That should just work, nothing else needed.

rneckelmann

Aug 20, 2010 at 4:58 AM

Quote:
Original post by cache_hit
Why not just only install the version of the assembly appropriate for the platform in question? If installing on a 64-bit system, only install the 64-bit assembly. I'm not sure I understand what problem the OP is trying to solve, because there is actually no problem. If you're on a 64-bit system, install all the 64-bit DLLs and EXEs that you compiled. If you're on a 32-bit system, install all the 32-bit DLLs and EXEs. That should just work, nothing else needed.

But what is the point with all those manifest files then?

Yann L

Aug 20, 2010 at 8:05 AM

Let the user choose. Provide two separate installers, one for 32bit and one for 64bit. Each one installs the respective binaries.

Do not try to force the user into installing a x64 version on a 64bit OS. Depending on your application, there can be very valid reasons to install the 32bit version running under Wow64.

cache_hit

Aug 20, 2010 at 11:16 AM

Quote:
Original post by rneckelmann
Quote:
Original post by cache_hit
Why not just only install the version of the assembly appropriate for the platform in question? If installing on a 64-bit system, only install the 64-bit assembly. I'm not sure I understand what problem the OP is trying to solve, because there is actually no problem. If you're on a 64-bit system, install all the 64-bit DLLs and EXEs that you compiled. If you're on a 32-bit system, install all the 32-bit DLLs and EXEs. That should just work, nothing else needed.

But what is the point with all those manifest files then?

Manifest files are most useful when there are multiple versions of the same DLL on the same machine. i.e. a bunch of DLLs with the same exact filename, usually installed in the Global Assembly Cache that are shared across many applications. Some applications might require one version, another application might require another version.

Manifests are also useful when your application requires special privileges to run, like it needs to display the Run as Administrator dialog on Vista+.

cache_hit

Aug 20, 2010 at 1:06 PM

Quote:
Original post by Yann L
Let the user choose. Provide two separate installers, one for 32bit and one for 64bit. Each one installs the respective binaries.

Do not try to force the user into installing a x64 version on a 64bit OS. Depending on your application, there can be very valid reasons to install the 32bit version running under Wow64.

I would actually beg to differ. Unless your target audience is mostly power users, I don't think normal people know or care about the difference, and as such you should almost definitely not ask them which version to install. I prefer to always install a version native to the OS they're running on unless there is a very good reason not to do so, such as significant increased development effort. But nowadays, it is almost a non-issue making programs work correctly in 64-bit unless you depend on 3rd party libraries which don't properly support 64-bit.

Nik02

Aug 20, 2010 at 1:27 PM

Quote:
Original post by cache_hit
unless you depend on 3rd party libraries which don't properly support 64-bit.

This applies to almost all professional content creation programs (for example, Photoshop CS4 and CS5) which use plugins in a precompiled binary format. It is not safe to assume that users will always be able to use the latest and greatest extension modules, and some plugins may never be ported to 64-bit at all for various reasons - no matter how useful they are.

rneckelmann

Aug 20, 2010 at 1:59 PM

Quote:
Original post by cache_hit
Manifest files are most useful when there are multiple versions of the same DLL on the same machine. i.e. a bunch of DLLs with the same exact filename, usually installed in the Global Assembly Cache that are shared across many applications. Some applications might require one version, another application might require another version.

So, basically, Global Assembly Cache is what unix people would call /usr/lib? And instead of just attaching a version tag to the file name you got manifest files?

A shame it don't seem to be standard for 3rd-party library developers to distribute Windows releases in this way.

Anyway, thanks, nice with some keywords to help my googling :)

Yann L

Aug 20, 2010 at 2:03 PM

Quote:
Original post by cache_hit
I would actually beg to differ. Unless your target audience is mostly power users, I don't think normal people know or care about the difference, and as such you should almost definitely not ask them which version to install. I prefer to always install a version native to the OS they're running on unless there is a very good reason not to do so, such as significant increased development effort. But nowadays, it is almost a non-issue making programs work correctly in 64-bit unless you depend on 3rd party libraries which don't properly support 64-bit.

As Nik02 already mentioned, third party plugins are a major source of problems. Second, memory use of applications that store a lot of pointers can very significantly increase under x64. This can bring you into a paradoxical situation, where the 64bit version of an application will run out of memory, while the 32bit version of same application works fine under Wow64 (yes 3DSMax 2010, I'm looking at you here. Seems to be better with 2011 though).

That's why you should definitely supply two installers. You can always have a generic setup.exe, which will launch the appropriate MSI depending on OS, if you want to make it straightforward for the casual user.

cache_hit

Aug 20, 2010 at 2:14 PM

Quote:
Original post by Yann L
Quote:
Original post by cache_hit
I would actually beg to differ. Unless your target audience is mostly power users, I don't think normal people know or care about the difference, and as such you should almost definitely not ask them which version to install. I prefer to always install a version native to the OS they're running on unless there is a very good reason not to do so, such as significant increased development effort. But nowadays, it is almost a non-issue making programs work correctly in 64-bit unless you depend on 3rd party libraries which don't properly support 64-bit.

As Nik02 already mentioned, third party plugins are a major source of problems.

This is one of those cases where you have a very good reason to install a specific version :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.