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

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

From reading the documentation, I saw this:

Quote:

---

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.

Reading the documentation a bit more, I found this:

Quote:

---

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.

Using a console application, I did this:

vb.net Code:

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.)

Quote:

---

Originally Posted by formlesstree4

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.

No problem.

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.

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

Code:

---

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

---

If not, try jmcilhinney's suggestion here.

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

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

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 :)

Code:

---

Environment.Is64BitOperatingSystem

---

and there is also

Code:

---

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

vb.net Code:

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)

Can't we just do that ourselves perhaps?

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

Quote:

---

Originally Posted by chris128

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.

Quote:

---

Originally Posted by formlesstree4

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.

vb.net Code:

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

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:

vb Code:

'
   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

what does stepping through reveal?

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

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..

Quote:

---

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?

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

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?

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 ;)

Quote:

---

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.

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 :p

Quote:

---

Originally Posted by 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 :p

---

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! :D