Detect when in 64bit OS

[Eric Renken]

Is there something in System.Environm ent that can tell me if the program is
running on a 64bit OS? What I am thinking is right now is to check the size
of IntPtr and if it is 4 then it is 32bit, but if it is 8 then it is 64bit.

Thanks,

Eric Renken

[=?Utf-8?B?ZGxncHJvYw==?=]

Can you determine it from Environment.OSV ersion.Version?

"Eric Renken" wrote:

Is there something in System.Environm ent that can tell me if the program is
running on a 64bit OS? What I am thinking is right now is to check the size
of IntPtr and if it is 4 then it is 32bit, but if it is 8 then it is 64bit.

Thanks,

Eric Renken

[Mark Rae]

"Eric Renken" <Er********@new sgroup.nospamwr ote in message
news:ex******** ******@TK2MSFTN GP05.phx.gbl...

Is there something in System.Environm ent that can tell me if the program
is running on a 64bit OS? What I am thinking is right now is to check the
size of IntPtr and if it is 4 then it is 32bit, but if it is 8 then it is
64bit.

No need to mess around with IntPtr:
http://msdn2.microsoft.com/En-US/library/aa394239.aspx

If you're running on a 64-bit OS, the OSArchitecture property will return
"64-bit" as a string...
--
http://www.markrae.net

[Mattias Sjögren]

>No need to mess around with IntPtr:

>http://msdn2.microsoft.com/En-US/library/aa394239.aspx

What exactly is messy with checking IntPtr.Size? I can't think of
anything more straight forward. Call it premature optimization if you
want, but I also bet that it's significantly faster than anything
involving WMI.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Chris Mullins [MVP]]

"Eric Renken" <Er********@new sgroup.nospamwr ote:

Is there something in System.Environm ent that can tell me if the program
is running on a 64bit OS? What I am thinking is right now is to check the
size of IntPtr and if it is 4 then it is 32bit, but if it is 8 then it is
64bit.

If you're trying to figure out, "Is my app running in 32 or 64 bit mode?"
then IntPtr is the best way to go. That's how we do it in our applications,
and it works great.

If you're trying to figure out, "Am I running in 32 bit mode on a 64 bit
machine?" then things are a bit harder. For instance, it bit us in an
installer which did some registry settings stuff, and ended up with
Windows-On-Windows issues
(http://www.thescripts.com/forum/thread558929.html)

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

[Nicholas Paldino [.NET/C# MVP]]

The only time I think it could be an issue is when running under 32-bit
mode, in which case, I would suspect IntPtr would be sized to 32 bits. If
the OP wants to get the platform regardless of which mode he is running
under, then the WMI way might be better.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Mattias Sjögren" <ma************ ********@mvps.o rgwrote in message
news:u4******** ******@TK2MSFTN GP06.phx.gbl...

No need to mess around with IntPtr:
http://msdn2.microsoft.com/En-US/library/aa394239.aspx

What exactly is messy with checking IntPtr.Size? I can't think of
anything more straight forward. Call it premature optimization if you
want, but I also bet that it's significantly faster than anything
involving WMI.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Willy Denoyette [MVP]]

"Eric Renken" <Er********@new sgroup.nospamwr ote in message
news:ex******** ******@TK2MSFTN GP05.phx.gbl...

Is there something in System.Environm ent that can tell me if the program
is running on a 64bit OS? What I am thinking is right now is to check the
size of IntPtr and if it is 4 then it is 32bit, but if it is 8 then it is
64bit.

Thanks,

Eric Renken

It's not that important to know whether you are running on 64 bit Windows,
what counts is whether you are running as a 64 bit or 32 bit application,
and the sizeof IntPtr is the right way to check this.

Willy.

[Mark Rae]

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard .caspershouse.c omwrote in
message news:OI******** ******@TK2MSFTN GP06.phx.gbl...

The only time I think it could be an issue is when running under 32-bit
mode, in which case, I would suspect IntPtr would be sized to 32 bits. If
the OP wants to get the platform regardless of which mode he is running
under, then the WMI way might be better.

Exactly.
--
http://www.markrae.net

[Mark Rae]

"Chris Mullins [MVP]" <cm******@yahoo .comwrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

If you're trying to figure out, "Is my app running in 32 or 64 bit mode?"
then IntPtr is the best way to go. That's how we do it in our
applications, and it works great.

If you're trying to figure out, "Am I running in 32 bit mode on a 64 bit
machine?" then things are a bit harder. For instance, it bit us in an
installer which did some registry settings stuff, and ended up with
Windows-On-Windows issues

That's exactly right, which is why WMI is the right way to do it.
--
http://www.markrae.net

[Chris Mullins [MVP]]

"Mark Rae" <ma**@markNOSPA Mrae.netwrote:

"Chris Mullins [MVP]" <cm******@yahoo .comwrote in message

>If you're trying to figure out, "Am I running in 32 bit mode on a 64 bit
machine?" then things are a bit harder. For instance, it bit us in an
installer which did some registry settings stuff, and ended up with
Windows-On-Windows issues

That's exactly right, which is why WMI is the right way to do it.

I think you misunderstood what I meant. Telling which OS and which
architecture you're running on are pretty easy, really. Knowing what to do
with that data is pretty hard.

For example, if you write to the registry from a 32 bit app, then try to
read back the same key in a 64 bit app, you'll get totally different data.
This is due to the Wow6432Node, which does some tricky things that you just
have to know about.

This bit us during install - our installer is a 32 bit app, that pokes
around a bit then installs a 64 bit application. Everything worked great,
expect for the fact that it didn't work at all. Using WMI or using the size
of the IntPtr wouldn't have made any difference at all. The installer
correctly figured everything out, it was just unable to do what it needed to
do...

There are (I suspect) a number of other areas like this, although none
spring to mind immediatly. Well, ok, a few do - Mostly memory management
related, such as where the DLL's are mapped into the process space, where
the real Windows DLL's live in memory, I bet there are all sorts of Loader
and Rebasing differences, etc.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins