[RESOLVED] [2005] detect 64bit os

LS,

I would like to know if someone has a easy way to determinte if the OS my program is running on is x64 or 32bit?

So to be clear, I don't wanna know if my processer supports x64, I wanna know if the windows version is either 64 bits or 32 bits.

I've tried searching the forums and google, no succes..

Thanks in advance!

Would this work?

vb Code:

Me.Text = My.Computer.Info.OSPlatform.ToString

great thanks resolved!

this doesnt not work... it replies back winNT32 to me, im running vista ultimate 64bit...

You have to use wmi into your vb code.

see if My.Computer.Info.OSFullName
contains the string "x64"

"x86" = 32 bit

this is how you do it

vb.net Code:

Dim architecture As Integer = Runtime.InteropServices.Marshal.SizeOf(GetType(IntPtr)) * 8
 
if architecture = 32 then
 
ElseIf architecture = 64 Then
 
endif

aren't there two versions of wmi, one for 32 and one for 64?

you can use the 32 bit version. You need only to search the "x64" string into the fields resulting from the following query:

New ManagementObjectSearcher("SELECT * FROM Win32_OperatingSystem")

My.Computer.Info.OSFullName contains x64(64 bit) or x86(32 bit). wmi queries are slow, IMHO.

What's with the bringing up of ancient threads about this?
I already wrote today that it is enough to directly check the size of intptr.

MessageBox.Show(IntPtr.Size.ToString)

i write / compile an application named foo with a 32 bit target platform.

then i run foo on a 64 bit os.

what size is intptr when foo runs on a 64 bit machine?

IntPtr is an integer with a twist. Something like the integer in vb6 and vb .net and later. In 6 an integer is 16 bit, in .net it is 32 bit.

Quote:

---

Originally Posted by MSDN

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.

---

If foo uses an IntPtr, it will be 8 bytes on a 64 bit OS, provided foo manages to start of course.

Quote:

---

Originally Posted by Half

What's with the bringing up of ancient threads about this?
I already wrote today that it is enough to directly check the size of intptr.

MessageBox.Show(IntPtr.Size.ToString)

---

Very clever though I just tried running this code on my Vista 64-bit machine and it returned a 4 :confused:

Edit: Actually it appears ASP.Net applications, regardless of what the build options are set to, run in 32-bit mode as this code returns a 4 on my 64-bit system. If I create a new Windows Forms project then this works correctly. Interesting...

"The IntPtr type is designed to be an integer whose size is platform-specific." That is what I am asking. Isn't it the target as specified at compile time? Or are you implying the data type changes structure at run-time?

If foo is targeted at 32 bit os, doesn't it have to run under WOW64 on a 64 bit os, which I think returns 4 as the size of intptr?

i guess if i had a 64 bit os i'd know the answer.

If ASP supports only 4 byte IntPtrs, it won't be able to use memory above the 4th gb mark. So either ASP is 32 bit only or there is more to it.

This supposedly can 'make' ASP 64bit.

dbasnett's doubts are valid unfortunately. IntPtr.Size is a hard coded property that is conditionally compiled to be either 4 or 8 depending on whether you're in a process that loaded up the 32bit version of mscorlib.dll or the 64bit version.

i guess it is good we brought it up.

Quote:

---

Originally Posted by Half

dbasnett's doubts are valid unfortunately. IntPtr.Size is a hard coded property that is conditionally compiled to be either 4 or 8 depending on whether you're in a process that loaded up the 32bit version of mscorlib.dll or the 64bit version.

---

I think your method is still good. Your method will show whether the process is running in a 32-bit or 64-bit mode. This is potentially better than the WMI solution depending on your purposes.

Let's say you have to interface with a native DLL but there is a 32-bit and a 64-bit version for performance purposes. Using your method would allow you to dynamically choose the correct one no matter what. Even if your application runs on a 64-bit machine but is forced to run in 32-bit mode it will still work perfectly.

If you're attempting to do the same thing via WMI and your application is really running in 32-bit mode on a 64-bit machine, it's going to crash and burn.

This is exceptionally useful in a .Net library as it could be used in ASP.Net or Windows Forms applications.

you all are just trying to make this harder than it is. if My.Computer.Info.OSFullName contains the string "x64" then you are running a 64 bit os, and i am going out on a limb here;), it is probably a 64 bit machine;). And it will say that even if your app was written for a 32 bit platform.

Quote:

---

Originally Posted by dbasnett

you all are just trying to make this harder than it is. if My.Computer.Info.OSFullName contains the string "x64" then you are running a 64 bit os, and i am going out on a limb here;), it is probably a 64 bit machine;). And it will say that even if your app was written for a 32 bit platform.

---

You already stated this... what was your point and who was making it harder? :confused:

The IntPtr method, as we were discussing, will show if your application is being run in 32-bit or 64-bit mode where as your method will only show if you're running on a 32-bit of 64-bit machine. Not exactly the same thing and while your solution is [probably] the most appropriate for the op, I was just trying to state that the IntPtr method can still be useful.