Detect when in 64bit OS

  • Thread starter Thread starter Eric Renken
  • Start date Start date
E

Eric Renken

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
 
Eric Renken said:
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)
 
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.
 
Eric Renken said:
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.
 
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.
 
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.
 
Mark Rae said:
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 said:
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().Token))
// better add a manifest to your application if you end here ;-)

Willy.
 
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 said:
Chris Mullins said:
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().Token))
// better add a manifest to your application if you end here
;-)

Willy.
 
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
 
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 said:
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 said:
Chris Mullins said:
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().Token))
// better add a manifest to your application if you end here
;-)

Willy.
 
Alvin Bruney said:
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.
 
Willy Denoyette said:
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...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top