[RESOLVED] Determining Architecture of OS (x86 or x64)

[weirddemon]

When trying to determine the Architecture of an OS, I ran across IntPtr.

From reading the documentation, I saw this:

The IntPtr type is designed to be an integer whose size is platform-specific. That is, an instance of this type is expected to be 32-bits on 32-bit hardware and operating systems, and 64-bits on 64-bit hardware and operating systems.

Since the size of IntPtr is intended to be the size of the architecture, would it be feasible to test the size and determine the OS by that? Or is there a better way?

I was thinking there might also be a way via WMI, but I don't want to use that for compatibility reason.

[weirddemon]

Reading the documentation a bit more, I found this:

The size of a pointer or handle on this platform, measured in bytes. The value of this property is 4 on a 32-bit platform, and 8 on a 64-bit platform

So it seems it will work, but I wonder how reliable this would be.

[formlesstree4]

Using a console application, I did this:

Module Module1
    Sub Main()
        Select Case IntPtr.Size
            Case "4"
                Console.WriteLine("32-bit Platform Detected!")
            Case "8"
                Console.WriteLine("64-bit Platform Detected!")
            Case Else
                Console.WriteLine("No clue what architecture this is!")
        End Select
        System.Threading.Thread.Sleep(3000)
    End Sub
End Module

I have a 64-bit OS and it wrote that it found a 64-bit. My friend has a 32-bit OS and it said it was a 32-Bit. I think we can say IntPtr is reliable as of this state (well at least on my two tests.)

[weirddemon]

Using a console application, I did this:
I have a 64-bit OS and it wrote that it found a 64-bit. My friend has a 32-bit OS and it said it was a 32-Bit. I think we can say IntPtr is reliable as of this state (well at least on my two tests.)

Thanks Formless. I had tested it on my machine, but wasn't sure how reliable it would be.

It worked just fine on my machine and it seems it works just fine on your and your friends'. So, I would say it's reliable enough.

Thanks again.

[formlesstree4]

No problem.

[chris128]

If your program is compiled to x86 then that will not work though because on a 64-bit OS it will run the program as if it were 32-bit (for compatibility obviously) and that includes 'pretending' that IntPtr's are only 4 bytes long.

[Half]

There were some lengthy threads about this and the size of the intptr structure can indeed only give you an idea if the process is running in a 32 bit environment (emulated or not). This is usefull for api signatures and whatnot.

See if the following could be useful to you

MessageBox.Show(System.Environment.GetEnvironmentVariable("PROCESSOR_ARCHITECTURE"))

If not, try jmcilhinney's suggestion here.

[chris128]

Weird that when I run that I get "AMD64" as the result, when I'm on an Intel processor.

[Half]

It's the number that counts & you've been scammed

[chris128]

Just wanted to update this thread with something that is new in .NET 4.0 as I noticed a link to this thread was in a couple of people's signatures. In .NET 4.0 you can use the following to determine if you are running on a 64 bit OS

Environment.Is64BitOperatingSystem

and there is also

Environment.Is64BitProcess

which determines if the current process (doesnt look like there is any way to run it against external processes) is 64 bit.

The way it actually works internally is kind of interesting, here's the definition of the GET for the Is64BitOperatingSystem property

Public Shared Function get_Is64BitOperatingSystem() As Boolean
    Dim flag As Boolean
    Return ((Win32Native.DoesWin32MethodExist("kernel32.dll", "IsWow64Process") AndAlso Win32Native.IsWow64Process(Win32Native.GetCurrentProcess, flag)) AndAlso flag)
End Function

so it looks like it just checks to see if the IsWow64Process method exists in the kernel32.dll file

The Is64BitProcess property is a bit more confusing though as it just returns False and that is it :S

EDIT: Ahh this article explains why - http://alexmg.com/post/2009/12/21/Is...in-NET-40.aspx (basically because I was looking at the 32 bit version of the framework DLLs)

[formlesstree4]

Can't we just do that ourselves perhaps?

EDIT: I mean check for the Method in kernel32.dll.

[MattP]

Weird that when I run that I get "AMD64" as the result, when I'm on an Intel processor.

64 bit OSes will return AMD64 regardless of whether they're AMD or Intel and 32 bit wil return x86.

Good to know about the .NET 4.0 changes.

[chris128]

Can't we just do that ourselves perhaps?

EDIT: I mean check for the Method in kernel32.dll.

I assume you mean if you are still working with pre .NET 4.0 code yeah?

As the article I linked to in my post explains, there are 2 versions of the core Framework DLL (mscorlib), one for 32 bit and one for 64 bit and obviously the relevant one gets loaded depending on which system you are running on. So in the 32 bit version which I was looking at, it does that check for the method, however in the 64 bit version of mscorlib it just returns True no matter what, because the 64 bit version can only be loaded on a 64 bit OS.

So its not quite as black and white as I initially thought when I posted that, but yeah if you can figure out how to check for the existence of a method in a C++ DLL then I guess you could use that as your test.
Here are the definitions of the methods that the property is using to check for the method existing but no idea if that will work just copying and pasting it... Perhaps this code for checking for a method existing in a DLL could be useful for something else as well.

Friend Shared Function DoesWin32MethodExist(ByVal moduleName As String, ByVal methodName As String) As Boolean
    Dim moduleHandle As IntPtr = Win32Native.GetModuleHandle(moduleName)
    If (moduleHandle = IntPtr.Zero) Then
        Return False
    End If
    Return (Win32Native.GetProcAddress(moduleHandle, methodName) <> IntPtr.Zero)
End Function
 
<ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail), DllImport("kernel32.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _
Private Shared Function GetModuleHandle(ByVal moduleName As String) As IntPtr
End Function
 
 
<DllImport("kernel32.dll", CharSet:=CharSet.Ansi, SetLastError:=True, ExactSpelling:=True)> _
Private Shared Function GetProcAddress(ByVal hModule As IntPtr, ByVal methodName As String) As IntPtr
End Function

[chris128]

Tried it and it doesnt seem to work no errors or anything, just returns False when it should return True...
EDIT: Ah no it does work but only if the process is running on a 64 bit OS but as a 32 bit process... sure there will be a way to adapt it to give an accurate answer no matter what though - give me a few minutes

Here's the code I'm using:

'
   Friend Shared Function DoesWin32MethodExist(ByVal moduleName As String, ByVal methodName As String) As Boolean
        Dim moduleHandle As IntPtr = GetModuleHandle(moduleName)
        If (moduleHandle = IntPtr.Zero) Then
            Return False
        End If
        Return (GetProcAddress(moduleHandle, methodName) <> IntPtr.Zero)
    End Function
 
    <ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail), DllImport("kernel32.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _
    Private Shared Function GetModuleHandle(ByVal moduleName As String) As IntPtr
    End Function
 
 
    <DllImport("kernel32.dll", CharSet:=CharSet.Ansi, SetLastError:=True, ExactSpelling:=True)> _
    Private Shared Function GetProcAddress(ByVal hModule As IntPtr, ByVal methodName As String) As IntPtr
    End Function
 
    <DllImport("kernel32.dll", SetLastError:=True)> _
    Friend Shared Function IsWow64Process(<[In]()> ByVal hSourceProcessHandle As IntPtr, <Out(), MarshalAs(UnmanagedType.Bool)> ByRef isWow64 As Boolean) As <MarshalAs(UnmanagedType.Bool)> Boolean
    End Function
 
    <DllImport("kernel32.dll", CharSet:=CharSet.Auto, SetLastError:=True)> _
    Friend Shared Function GetCurrentProcess() As IntPtr
    End Function
 
 
    Public ReadOnly Property Is64BitOperatingSystem() As Boolean
        Get
            Dim flag As Boolean
            Return ((DoesWin32MethodExist("kernel32.dll", "IsWow64Process") AndAlso IsWow64Process(GetCurrentProcess, flag)) AndAlso flag)
        End Get
    End Property

[formlesstree4]

what does stepping through reveal?

[chris128]

Not a lot as the majority of it is API calls. I've just found out though that you cant use this to determine if an OS is 64 bit because the IsWow64Process method exists in 32 bit versions of the Windows kernel as well so it looks like the .NET framework basically already knows what architecture it is running as but just uses this method to check to make sure it is not a 32 bit process running on a 64 bit system - so it checks to make sure the method exists, then calls it on the current process. I think the reason it checks for the existence of the method first is because the method only exists in kernel32.dll in XP SP2 onwards.

However I think we can still make use of it - you just use the property that I posted in my previous post first and if it returns True then you know you are on a 64 bit OS but you are running as a 32 bit process (which is where IntPtr cant help you). If it returns false then you check the size of IntPtr, because if it returned false then you are either on a 64 bit OS and you are running as a 64 bit process (therefore IntPtr = 8) or you are a 32 bit process running on a 32 bit OS (so IntPtr = 4).

Having said that, it is much simpler and easier to just check the

[chris128]

for gods sake I just realised that JMC already posted a much simpler way of doing this that I completely missed haha http://www.vbforums.com/showpost.php...17&postcount=2
EDIT: Though it is not perfect as it does not check for the existence of the IsWow64Process before calling it so it would crash on a pre SP2 XP machine..

[formlesstree4]

Having said that, it is much simpler and easier to just check the

The what? That made me laugh for a few minutes, didn't finish your train of thought?

[chris128]

haha I have no idea what I was going to say there...

EDIT: Here's a codebank thread I just made that should provide a fool proof way of checking for a 64 bit OS http://www.vbforums.com/showthread.php?t=613889

[weirddemon]

That's awesome, Chris. I've never run into an issue with IntPtr yet, but I'm bound to.

I'm curious though, if JMC's example worked, why would I want to use the one you've posted? If they both do the same thing, wouldn't I choose the example with fewer lines of code?

[weirddemon]

Err... disregard last post, I guess. I just saw where you said his code crashes on pre XP SP2 machines.

Though at this point, running XP in general is just silly

[formlesstree4]

Though at this point, running XP in general is just silly

Despite most PC's running XP at this point? I dunno man....it is still wise to develop for XP and above until XP's support is phased out completely, and even a few years afterwards.

[weirddemon]

I was being facetious. I know it's hard to convey inflection and sarcasm through our posts, but I was hoping the wink would suffice.

Also, I was kind of hoping Minitech would see this post. I'm always giving him a hard time about not adopting new technology

[formlesstree4]

I was being facetious. I know it's hard to convey inflection and sarcasm through our posts, but I was hoping the wink would suffice.

Also, I was kind of hoping Minitech would see this post. I'm always giving him a hard time about not adopting new technology

I did not seem to put two and two together to make four, but instead twenty two. Basically, I overlooked it completely.

As for Minitech, he'll come around eventually. He's bound to!