On which OS Architecture i am 32 Bit or 64 Bit, Can c++ tell me?
-
Hey Friends I need to know in an application whether the OS is 32 or 64 Bit. My Code is compiled in 32 bit and is running on a 64 bit pc. Tried if(sizeof(void *)==8) { //64 Bit } else { //32 Bit } Does not Works Regards
My Company
-
Hey Friends I need to know in an application whether the OS is 32 or 64 Bit. My Code is compiled in 32 bit and is running on a 64 bit pc. Tried if(sizeof(void *)==8) { //64 Bit } else { //32 Bit } Does not Works Regards
My Company
there is at least one Tip/Trick on this subject, with some alternates; none of them I consider satisfactory though, and I haven't found the right approach yet. There are three levels to the problem: - what is my application doing? - what is my operating system capable of? - if running on a virtual machine, what is my physical machine capable of? First make sure which question you need answered. FWIW: Are you sure you want a managed code (i.e. .NET) solution, or are you a native C++ speaker, simply lost in the wrong forum? (the C/C++/MFC forum is for native code!). :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
Hey Friends I need to know in an application whether the OS is 32 or 64 Bit. My Code is compiled in 32 bit and is running on a 64 bit pc. Tried if(sizeof(void *)==8) { //64 Bit } else { //32 Bit } Does not Works Regards
My Company
This will never work because
sizeof()is evaluated by the compiler so it will tell you the size of avoid*on the system that it is compiled on. I just tried a Google on this and there does not seem to be an obvious answer to do it programatically; maybe one of the other geeks here knows the answer.Just say 'NO' to evaluated arguments for diadic functions! Ash
-
there is at least one Tip/Trick on this subject, with some alternates; none of them I consider satisfactory though, and I haven't found the right approach yet. There are three levels to the problem: - what is my application doing? - what is my operating system capable of? - if running on a virtual machine, what is my physical machine capable of? First make sure which question you need answered. FWIW: Are you sure you want a managed code (i.e. .NET) solution, or are you a native C++ speaker, simply lost in the wrong forum? (the C/C++/MFC forum is for native code!). :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
Hey Friends I need to know in an application whether the OS is 32 or 64 Bit. My Code is compiled in 32 bit and is running on a 64 bit pc. Tried if(sizeof(void *)==8) { //64 Bit } else { //32 Bit } Does not Works Regards
My Company
What i understand is that you want to know that is OS is 32 bit or 64 bit...
BOOL XYZ::Is64BitOS()
{
SYSTEM_INFO sysInfo;
GetSystemInfo(&sysInfo);
if((sysInfo.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64) || (sysInfo.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_IA64))
return TRUE;
return FALSE;
}Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
-
What i understand is that you want to know that is OS is 32 bit or 64 bit...
BOOL XYZ::Is64BitOS()
{
SYSTEM_INFO sysInfo;
GetSystemInfo(&sysInfo);
if((sysInfo.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64) || (sysInfo.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_IA64))
return TRUE;
return FALSE;
}Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
Hey thanks, you got it correct but somehow the code did not worked, but i googled with your input and found an alternative which worked. BOOL Is64BitWindows() { #if defined(_WIN64) return TRUE; // 64-bit programs run only on Win64 #elif defined(_WIN32) // 32-bit programs run on both 32-bit and 64-bit Windows // so must sniff BOOL f64 = FALSE; return IsWow64Process(GetCurrentProcess(), &f64) && f64; #else return FALSE; // Win64 does not support Win16 #endif } Thanks a lot.
Goa Guy
-
Hey thanks, you got it correct but somehow the code did not worked, but i googled with your input and found an alternative which worked. BOOL Is64BitWindows() { #if defined(_WIN64) return TRUE; // 64-bit programs run only on Win64 #elif defined(_WIN32) // 32-bit programs run on both 32-bit and 64-bit Windows // so must sniff BOOL f64 = FALSE; return IsWow64Process(GetCurrentProcess(), &f64) && f64; #else return FALSE; // Win64 does not support Win16 #endif } Thanks a lot.
Goa Guy
-
Hey thanks, you got it correct but somehow the code did not worked, but i googled with your input and found an alternative which worked. BOOL Is64BitWindows() { #if defined(_WIN64) return TRUE; // 64-bit programs run only on Win64 #elif defined(_WIN32) // 32-bit programs run on both 32-bit and 64-bit Windows // so must sniff BOOL f64 = FALSE; return IsWow64Process(GetCurrentProcess(), &f64) && f64; #else return FALSE; // Win64 does not support Win16 #endif } Thanks a lot.
Goa Guy
This is still wrong! If you compile this code on a system where
_WIN64is defined then the generated code will returnTRUEfrom theIs64BitWindows()function. However if you then run that same code on a 32 bit system it will still returnTRUEand your program will most likely fail. You need to understand the difference between compile time and run time tests.Just say 'NO' to evaluated arguments for diadic functions! Ash
-
This is still wrong! If you compile this code on a system where
_WIN64is defined then the generated code will returnTRUEfrom theIs64BitWindows()function. However if you then run that same code on a 32 bit system it will still returnTRUEand your program will most likely fail. You need to understand the difference between compile time and run time tests.Just say 'NO' to evaluated arguments for diadic functions! Ash
<blockquote class="FQ"><div class="FQA">Richard MacCutchan wrote:</div>This is still wrong! If you compile this code on a system where _WIN64 is defined then the generated code will return TRUE from the Is64BitWindows() function</blockquote> The _WIN64 macro is a Microsoft compiler option that indicates that the code is being compiled for 64 bits. The following link says that is what it is. http://msdn.microsoft.com/en-us/library/b0084kay.aspx[^] So excluding someone using that macro incorrectly (if even possible) the compiled code would then be compiled to run on 64 bits. And a 64 bit application won't run on a 32 bit machine - right? So what would be the situation where it returns an incorrect result?
-
<blockquote class="FQ"><div class="FQA">Richard MacCutchan wrote:</div>This is still wrong! If you compile this code on a system where _WIN64 is defined then the generated code will return TRUE from the Is64BitWindows() function</blockquote> The _WIN64 macro is a Microsoft compiler option that indicates that the code is being compiled for 64 bits. The following link says that is what it is. http://msdn.microsoft.com/en-us/library/b0084kay.aspx[^] So excluding someone using that macro incorrectly (if even possible) the compiled code would then be compiled to run on 64 bits. And a 64 bit application won't run on a 32 bit machine - right? So what would be the situation where it returns an incorrect result?
jschell wrote:
And a 64 bit application won't run on a 32 bit machine - right?
Correct.
jschell wrote:
So what would be the situation where it returns an incorrect result?
I'm not sure that I understand your question fully. However in the case above that I commented on, if the code is compiled on a system with
_WIN64defined, and then run on a 32 bit system, it wil returnTRUEfrom that function thus thinking that it is on a 64-bit system. I have no idea what the outcome would be but I would expect it to fail at some point.Just say 'NO' to evaluated arguments for diadic functions! Ash
-
Hey Friends I need to know in an application whether the OS is 32 or 64 Bit. My Code is compiled in 32 bit and is running on a 64 bit pc. Tried if(sizeof(void *)==8) { //64 Bit } else { //32 Bit } Does not Works Regards
My Company
-
jschell wrote:
And a 64 bit application won't run on a 32 bit machine - right?
Correct.
jschell wrote:
So what would be the situation where it returns an incorrect result?
I'm not sure that I understand your question fully. However in the case above that I commented on, if the code is compiled on a system with
_WIN64defined, and then run on a 32 bit system, it wil returnTRUEfrom that function thus thinking that it is on a 64-bit system. I have no idea what the outcome would be but I would expect it to fail at some point.Just say 'NO' to evaluated arguments for diadic functions! Ash
Richard MacCutchan wrote:
However in the case above that I commented on, if the code is compiled on a system with _WIN64 defined, and then run on a 32 bit system, it wil return TRUE from that function thus thinking that it is on a 64-bit system.
The _WIN64 is a VS compiler macro that is only defined when VS is set up to compile to a 64 bit binary. A 64 bit binary will not run on a 32 bit platform. If both of those are true then the result of the method is irrelevant. Do you believe that one of those is false? If so why?
-
Richard MacCutchan wrote:
However in the case above that I commented on, if the code is compiled on a system with _WIN64 defined, and then run on a 32 bit system, it wil return TRUE from that function thus thinking that it is on a 64-bit system.
The _WIN64 is a VS compiler macro that is only defined when VS is set up to compile to a 64 bit binary. A 64 bit binary will not run on a 32 bit platform. If both of those are true then the result of the method is irrelevant. Do you believe that one of those is false? If so why?
-
Richard MacCutchan wrote:
However in the case above that I commented on, if the code is compiled on a system with _WIN64 defined, and then run on a 32 bit system, it wil return TRUE from that function thus thinking that it is on a 64-bit system.
The _WIN64 is a VS compiler macro that is only defined when VS is set up to compile to a 64 bit binary. A 64 bit binary will not run on a 32 bit platform. If both of those are true then the result of the method is irrelevant. Do you believe that one of those is false? If so why?
I have been reflecting on this point and your answer. I think the reason for my comments was based on a situation I had when working on a multi-platform system some years ago. We had a similar situation where our manager insisted the code by written with
#ifdef's, even though we had explained to him that it needed to be execution time tests. After releasing the code we were proved right and the manager's career did not last much longer. As you pointed out, this situation is somewhat different.Just say 'NO' to evaluated arguments for diadic functions! Ash
-
I have been reflecting on this point and your answer. I think the reason for my comments was based on a situation I had when working on a multi-platform system some years ago. We had a similar situation where our manager insisted the code by written with
#ifdef's, even though we had explained to him that it needed to be execution time tests. After releasing the code we were proved right and the manager's career did not last much longer. As you pointed out, this situation is somewhat different.Just say 'NO' to evaluated arguments for diadic functions! Ash
Richard MacCutchan wrote:
We had a similar situation where our manager insisted the code by written with #ifdef's, even though we had explained to him that it needed to be execution time tests.
I don't understand that comment. If I am targetting a 32 bit platform and a 64 bit platform then I would really expect that I must run two complete set of tests, one on the 32 and one the 64 bit. And if the functionality was different at a minimum I would loudly and repeatedly state that I would expect it to fail if it wasn't tested on a specific target. I would be nervous even if it was exactly the same. Especially with C++ (or C.)
-
Richard MacCutchan wrote:
We had a similar situation where our manager insisted the code by written with #ifdef's, even though we had explained to him that it needed to be execution time tests.
I don't understand that comment. If I am targetting a 32 bit platform and a 64 bit platform then I would really expect that I must run two complete set of tests, one on the 32 and one the 64 bit. And if the functionality was different at a minimum I would loudly and repeatedly state that I would expect it to fail if it wasn't tested on a specific target. I would be nervous even if it was exactly the same. Especially with C++ (or C.)
-
Richard MacCutchan wrote:
We had a similar situation where our manager insisted the code by written with #ifdef's, even though we had explained to him that it needed to be execution time tests.
I don't understand that comment. If I am targetting a 32 bit platform and a 64 bit platform then I would really expect that I must run two complete set of tests, one on the 32 and one the 64 bit. And if the functionality was different at a minimum I would loudly and repeatedly state that I would expect it to fail if it wasn't tested on a specific target. I would be nervous even if it was exactly the same. Especially with C++ (or C.)
Essential, if you are compiling a 64 bit application, the compiler would define _WIN64 and since that application would not run on a 32 bit OS, then in that case, it is essentially pointless to actually check the OS. If the OS would have been 32 bits, the application would have fail to load. Identifier starting with underscore are supposed to be reserved to the compiler so if someone use them anyway the result might be undefined. Thus only when the application is compiled in 32 bits, it is necessary to do the test.
Philippe Mori