469,317 Members | 1,652 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,317 developers. It's quick & easy.

Detect when in 64bit OS

Is there something in System.Environment 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
May 31 '07 #1
15 17087
Can you determine it from Environment.OSVersion.Version?

"Eric Renken" wrote:
Is there something in System.Environment 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
May 31 '07 #2
"Eric Renken" <Er********@newsgroup.nospamwrote in message
news:ex**************@TK2MSFTNGP05.phx.gbl...
Is there something in System.Environment 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

May 31 '07 #3
>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.
May 31 '07 #4
"Eric Renken" <Er********@newsgroup.nospamwrote:
Is there something in System.Environment 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
May 31 '07 #5
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.com

"Mattias Sjögren" <ma********************@mvps.orgwrote in message
news:u4**************@TK2MSFTNGP06.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.

May 31 '07 #6
"Eric Renken" <Er********@newsgroup.nospamwrote in message
news:ex**************@TK2MSFTNGP05.phx.gbl...
Is there something in System.Environment 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.

May 31 '07 #7
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in
message news:OI**************@TK2MSFTNGP06.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

May 31 '07 #8
"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:%2****************@TK2MSFTNGP02.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

May 31 '07 #9
"Mark Rae" <ma**@markNOSPAMrae.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
May 31 '07 #10
"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:Op*************@TK2MSFTNGP05.phx.gbl...
"Mark Rae" <ma**@markNOSPAMrae.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 is the result of the "virtualization" of the registry, done when
running "legacy" 32 bit interactive applications under WOW64.
64 bit applications never run virtualized, nor do 32 or 64 bit services and
drivers.
Disabling "virtualization" will be done by default when using the Orcas
csharp compiler (and with the upcomming SP1 of Framework V2), pre-Orcas CSC
buids should include a manifest by running mt.exe in order to disable
"virtualization".
You can check whether "virtualization" is effective by inspecting the
access token of the current (non-impersonating) user like this:

[DllImport("advapi32.dll", EntryPoint = "GetTokenInformation",
SetLastError = true)]
static extern bool GetTokenInformationNative(
IntPtr TokenHandle,
int TokenInformationClass,
ref int TokenInformation,
int TokenInformationLength,
out int ReturnLength);

public bool IsVirtualized(IntPtr token)
{
bool virtualized = false;
int len = 4;
int info = 0;
if (!GetTokenInformationNative(token, 24, ref info, len, out
len)) // 24 = TokenVirtualizationEnabled
{
string s = "Win32 error " +
Marshal.GetLastWin32Error().ToString();
throw new Exception(s);
}
if(info != 0)
virtualized = true;
return virtualized;
}

// usage...

if(IsVirtualized(WindowsIdentity.GetCurrent().Toke n))
// better add a manifest to your application if you end here ;-)

Willy.

Jun 1 '07 #11
What kind of software do you work on, that you know this kind of stuff off
the top of your head?

It's just... scary! (I mean that in the best possible way)

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

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:C2**********************************@microsof t.com...
"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:Op*************@TK2MSFTNGP05.phx.gbl...
>"Mark Rae" <ma**@markNOSPAMrae.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 is the result of the "virtualization" of the registry, done when
running "legacy" 32 bit interactive applications under WOW64.
64 bit applications never run virtualized, nor do 32 or 64 bit services
and drivers.
Disabling "virtualization" will be done by default when using the Orcas
csharp compiler (and with the upcomming SP1 of Framework V2), pre-Orcas
CSC buids should include a manifest by running mt.exe in order to disable
"virtualization".
You can check whether "virtualization" is effective by inspecting the
access token of the current (non-impersonating) user like this:

[DllImport("advapi32.dll", EntryPoint = "GetTokenInformation",
SetLastError = true)]
static extern bool GetTokenInformationNative(
IntPtr TokenHandle,
int TokenInformationClass,
ref int TokenInformation,
int TokenInformationLength,
out int ReturnLength);

public bool IsVirtualized(IntPtr token)
{
bool virtualized = false;
int len = 4;
int info = 0;
if (!GetTokenInformationNative(token, 24, ref info, len, out
len)) // 24 = TokenVirtualizationEnabled
{
string s = "Win32 error " +
Marshal.GetLastWin32Error().ToString();
throw new Exception(s);
}
if(info != 0)
virtualized = true;
return virtualized;
}

// usage...

if(IsVirtualized(WindowsIdentity.GetCurrent().Toke n))
// better add a manifest to your application if you end here
;-)

Willy.

Jun 1 '07 #12
Well I guess I should have been a little more clear on why I am asking. A
hardware manufacture Dallas Maxim is updating their USB 1-wire device to
work on 64 and 32 bit machines, and I will need to know what mode the OS is
running under so I can call the correct DLL in my code. I think I will
stick with the size of the IntPrt for now.

And actually right now I am working on some communication with a HID device
from C# and have a grand old time trying to get them to work in 64bit mode.
I have fixed some of the problems by replacing the Int32 in the definitions
with IntPtr.

My program itself doesn't care what architecture it is running on it all
those darn hardware devices I need to communicate with that are the pain.

Thanks everyone and I have learned some stuff about virtualation reading all
this.

Eric Renken

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:98**********************************@microsof t.com...
"Eric Renken" <Er********@newsgroup.nospamwrote in message
news:ex**************@TK2MSFTNGP05.phx.gbl...
>Is there something in System.Environment 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.

Jun 1 '07 #13
What kind of software do you work on, that you know this kind of stuff off
the top of your head?

It's just... scary! (I mean that in the best possible way)
I know for a fact that Willy wrote a large part of the CLR all by himself
and then sold it to MS. He is quite rich as well!

--
Regards,
Alvin Bruney
------------------------------------------------------
Shameless author plug
Excel Services for .NET is coming...
https://www.microsoft.com/MSPress/books/10933.aspx
OWC Black Book www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley
"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:uE**************@TK2MSFTNGP06.phx.gbl...
What kind of software do you work on, that you know this kind of stuff off
the top of your head?

It's just... scary! (I mean that in the best possible way)

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

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:C2**********************************@microsof t.com...
>"Chris Mullins [MVP]" <cm******@yahoo.comwrote in message
news:Op*************@TK2MSFTNGP05.phx.gbl...
>>"Mark Rae" <ma**@markNOSPAMrae.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 is the result of the "virtualization" of the registry, done when
running "legacy" 32 bit interactive applications under WOW64.
64 bit applications never run virtualized, nor do 32 or 64 bit services
and drivers.
Disabling "virtualization" will be done by default when using the Orcas
csharp compiler (and with the upcomming SP1 of Framework V2), pre-Orcas
CSC buids should include a manifest by running mt.exe in order to disable
"virtualization".
You can check whether "virtualization" is effective by inspecting the
access token of the current (non-impersonating) user like this:

[DllImport("advapi32.dll", EntryPoint = "GetTokenInformation",
SetLastError = true)]
static extern bool GetTokenInformationNative(
IntPtr TokenHandle,
int TokenInformationClass,
ref int TokenInformation,
int TokenInformationLength,
out int ReturnLength);

public bool IsVirtualized(IntPtr token)
{
bool virtualized = false;
int len = 4;
int info = 0;
if (!GetTokenInformationNative(token, 24, ref info, len, out
len)) // 24 = TokenVirtualizationEnabled
{
string s = "Win32 error " +
Marshal.GetLastWin32Error().ToString();
throw new Exception(s);
}
if(info != 0)
virtualized = true;
return virtualized;
}

// usage...

if(IsVirtualized(WindowsIdentity.GetCurrent().Toke n))
// better add a manifest to your application if you end here
;-)

Willy.


Jun 2 '07 #14
"Alvin Bruney [MVP]" <some guy without an email addresswrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
>What kind of software do you work on, that you know this kind of stuff
off the top of your head?

It's just... scary! (I mean that in the best possible way)

I know for a fact that Willy wrote a large part of the CLR all by himself
and then sold it to MS. He is quite rich as well!

--
Alvin, weren't you told this was highly confidential? Now I'll have to
invite all MVP's to a party on my yacht I guess :-)).

Willy.

Jun 3 '07 #15
"Willy Denoyette [MVP]" <wi*************@telenet.bewrote
"Alvin Bruney [MVP]" <some guy without an email addresswrote:
>>What kind of software do you work on, that you know this kind of stuff
off the top of your head?

It's just... scary! (I mean that in the best possible way)

I know for a fact that Willy wrote a large part of the CLR all by himself
and then sold it to MS. He is quite rich as well!

Alvin, weren't you told this was highly confidential? Now I'll have to
invite all MVP's to a party on my yacht I guess :-)).
Well, in retrospect, I guess it's pretty obvious.

The first names are identical - William is both Willy or Bill.

It took me a bit to find the right anagram of Gates, but once I went
old-school ROT-13, ROT-47 and the original 1977 RSA algorithm (implemented
in BASIC) it was only a matter of time...

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

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Mat | last post: by
2 posts views Thread by Mike Stephens | last post: by
1 post views Thread by Eric Rupp via .NET 247 | last post: by
reply views Thread by john ciriello | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.