Determine if 32 or 64 bit system

Unity Engine
1

I am having a bit of a problem, but let me give you some context first. I am creating a game which involves interactions with robots. Rather than having voice acting, managing speech files, etc., I opted to use a speech generator for these robots. Initially I wanted to use the SpeechSynthesis class found in the System.Speech.Synthesis namespace, which the MSDN docs tell me is available from .NET 3.0 up, but I get an error when I try to use it, namely that Unity’s compiler can’t find the System.Speech namespace (Am I missing an assembly directive?). Then I got the idea (on these forums) to use an external speech engine and have Unity call that program. This works, somewhat.

I can use the System.Diagnostics.Process class to call the speech engine (eSpeak, http://espeak.sourceforge.net/), but i have to know where the speech engine is installed. I’ve noticed that 64-bit systems have a Program Files (x86) folder for 32-bit programs to install themselves in. As eSpeak is a 32-bit program, it installs itself there on my 64-bit laptop. I wast to be able to support 32-bit systems as well, so I need to be able to distinguish between these in order to know where eSpeak is installed so I can know how to call that.

I’ve tried using the PROCESSOR_ARCHITECTURE system variable in the following manner:

public bool is64Bit()
    {
        string pa = System.Environment.GetEnvironmentVariable("PROCESSOR_ARCHITECTURE");
        return ((System.String.IsNullOrEmpty(pa) || pa.Substring(0, 3) == "x86") ? false : true);
    }

but that tells me that the processor is 32-bit on my laptop, which I know is a 64-bit system.

My question is this: does anyone know how to determine if a Windows OS is 32 or 64 bit?

2

Regardless of the OS, your game is a 32-bit process, so you can just use GetEnvironmentVariable(“ProgramFiles”), which will magically point to the right place.

This is also why PROCESSOR_ARCHITECTURE is not working for you - it tells you what architecture your program is running on (i.e. always 32-bit for Unity), not what the OS is. To bypass the magic, use the unfortunately-named PROCESSOR_ARCHITEW6432. But you don’t need to.

3

That works beautifully. Thank you.

4

Thanks for this, mate! Works quite nicely for my little ad-hoc update system.

5

Just FYI, I was trying to use the PROCESSOR_ARCHITECTURE method of determining whether the Unity app was running in 32 or 64 bit mode (as a rough measure of how much memory the program can take advantage of), and it doesn’t seem to work for Mac.

For those that are trying to do the same thing, you can use IntPtr.Size as an alternative. On 32-bit systems, it will be 4 bytes, and on 64 bit systems it will be 8 bytes.

This method will allow you to determine whether the Unity app is 32-bit or 64-bit - if you want to know the underlying processor architecture, use gfoot’s method above.

1 Like
6

As an aside from the original question, I don’t think the approach taken (looking at specific paths) is a particularly robust solution regardless of system architecture. What if the application is installed in a non-default location?

I’ve never had to do it myself, but I suspect that there’d be some OS request you can make to see if an application is installed and where, and use that. The registry stores that information for anything that’s formally installed, and I’d be surprised if there wasn’t a way to query that.