Identifying if Windows is 32 or 64 bits

[Celeri]

Now here's a good one for you guys

I'm working on a small program to assist a client apply patches to his PCs using the infamous QChain program.

In order for the program to be as idiot-proof as possible, I need to know the following:

The user's version of Windows --> @OSVersion

The type of windows this is --> @OSTYPE

The language used --> @OSLang

Version and language are OK. My problem is with @OSType. Here's a direct quote from the help file (yes some of us do read it )

Returns "WIN32_NT" for NT/2000/XP/2003 and returns "WIN32_WINDOWS" for 95/98/Me

So is @OSType going to contain "WIN64_NT" if someone is using window's latest offering?

This is critically important for my program to work properly since installing patches for the wrong window type will result in an error. I'd like to intercept this error from within my program and not as a return parameter from the update files ...

Ok well I'll search the registry while waiting for an answer ... (I.E.: anyone out there with a 64 bit windows willing to try the folloing code?)

MsgBox(1,"Windows Type",@OSType)

Thanks a million

P.S.: Someone finds the answer, I'll post the final program on this forum

Edited August 10, 2005 by Celeri

[Celeri]

Ok well I've done my homework ... and so far no joy

Since I don't have access to a 64 bit version of XP it doesn't make it any easier ... and no thanks to Microsoft - MSDN is just a pain to decypher

(it usually beats up the noob within me)

BTW in case I wasn't clear, I don't want to know if the processor can handle 64 bits, I want to know if Windows can (not the same thing).

Thanks again

[hgeras]

Instead of using macros try to retrieve this info from registry....

e.g. "HK_Local_Machine\SOFTWARE\Windows NT\CurrentVersion\"

There are several keys there that have info about the operating system....

I cant know what the keys are like in x64 cos havent installed them yet...Someone else could give you this info...

Edited August 10, 2005 by hgeras

[/dev/null]

no thanks to Microsoft - MSDN is just a pain to decypher

(it usually beats up the noob within me)

what you need is this:

LINK1 and

LINK2

You will need DLLCall() and DLLStructCreate() etc. as well.

Cheers

Kurt

[hgeras]

I checked your links and it says that if return value is 2 in dwMinorVersion (OSVERSIONINFOEx) then it indicates that The operating system is Windows Server 2003 "R2", Windows Server 2003, or Windows XP Professional x64 Edition.So again there is no way to distinguish if it is a 64bit environment or not....

[/dev/null]

I checked your links and it says that if return value is 2 in dwMinorVersion (OSVERSIONINFOEx) then it indicates that The operating system is Windows Server 2003 "R2", Windows Server 2003, or Windows XP Professional x64 Edition.So again there is no way to distinguish if it is a 64bit environment or not....

<{POST_SNAPBACK}>

so, what do you think that x64 might mean? I associate it with Windows XP 64 Bit. And I think that is what Celeri is interested in.

Cheers

Kurt

[hgeras]

If you run the function in Windows server 2003 then:

dWMajorVersion= 5 and dWMinorVersion= 2

If you run the function in Windows XP x64 then:

dWMajorVersion = 5 and dWMinorVersion = 2

How are you going to tell which one is which?

[/dev/null]

How are you going to tell which one is which?

Ah, you are right. Maybe we need an additional function. GetSystemInfo() and the struct SYSTEM_INFO with "member" wProcessorArchitecture. LINK

Cheers

Kurt

[hgeras]

Yes you are right...But then gets too complicated.... I believe the key "ProductName" in "HK_Local_Machine\SOFTWARE\Windows NT\CurrentVersion\" is much easier to access and might do the trick...Unless he wants some practice in DllStruct() !!!

C ya

[Celeri]

Yes you are right...But then gets too complicated.... I believe the key "ProductName" in "HK_Local_Machine\SOFTWARE\Windows NT\CurrentVersion\" is much easier to access and might do the trick...Unless he wants some practice in DllStruct() !!!

C ya

<{POST_SNAPBACK}>

WOW thanks for the quick reply, I'm blown away! (can you see I'm having fun with these smilies?)

BTW the correct registry branch is HKLM\Software\Microsoft\Windows NT\CurrentVersion (I've learned by borking the registry over and over and over and over ...) ... but sadly ProductName is as generic as can be ... unless it ends in x64 when the OS is 64 bit, in which case that would be sufficient for me.

Oh thanks another million to /dev/null for the links, which are excellent! But I fear this link is the better alternative; so happens when you run 32bit code on a 64bit system, it goes through something called WOW (windows on windows). If the value is true than voilà, 64 bits it is. Sadly it's not going to happen (with me at least). I have another idea

But what really boggles the mind is the fact that there is no *real* provision (from MicroSlouch that is) to see if the OS can handle 64 bit code. Like I said before I made quite a bit of research today for an external alternative and I'm really amazed by the fact that no one (even MSDN!) seems to think it's important to know!!! I mean how hard is it to program IS_OS_64BITS? You'd figure after all the marketing, hype and stuff ...

Anyways I think I'll go for the really cheap alternative of trying to find a system file that's present in the 64bit version but not on the 32bit one. If that fails then it's either going to be that DLL thingie or a giant prompt when starting the program:

"THOU SHALL NOT RUN 32BIT PATCHES ON THY 64BIT OS"

And as promised, as soon as I have something substantial, I will post it here (err... in scripts and scraps that is!!)

Edited August 11, 2005 by Celeri

[Holger]

I ask jpm again to implement an advancing of the macro "OS_TYPE" with "WIN64_NT".

Regards

Holger

[Celeri]

I ask jpm again to implement an advancing of the macro "OS_TYPE" with "WIN64_NT".

Regards

Holger

<{POST_SNAPBACK}>

WOW thanks

If I find an alternative I'll let everyone know

Obi Wan Celeri

[jpm]

not to change what the Windows API return I will not change @OSTYPE to be as consistent as Windows is...

but I will add a @PROCESSORARCHITECTURE which will return IA32 IA64 X64

[Celeri]

not to change what the Windows API return I will not change @OSTYPE to be as consistent as Windows is...

but I will add a @PROCESSORARCHITECTURE which will return IA32 IA64 X64

<{POST_SNAPBACK}>

WOW just for moi? :">

BTW, if anyone knows a file or folder that exists ONLY in Windows XP X64, I would really appreciate that info ... so far I've dissected a whole bunch of updates for X64 and found no noticeable difference - except on the binary side that is ... Hmmm...

Allright well thank you all for your efforts!!!

Ah yes, my program is 50% complete - it should be on this forum by the week's end (if anyone interested that is)

[seandisanti]

WOW just for moi?  :">

BTW, if anyone knows a file or folder that exists ONLY in Windows XP X64, I would really appreciate that info ... so far I've dissected a whole bunch of updates for X64 and found no noticeable difference - except on the binary side that is ... Hmmm...

Allright well thank you all for your efforts!!!

Ah yes, my program is 50% complete - it should be on this forum by the week's end (if anyone interested that is)

<{POST_SNAPBACK}>

actually, you've already made mention of WoW, which would not be necessary on any system without XP X64 right? why not research up on that WoW on MSDN and see what lib/dll it's in...

[Celeri]

actually, you've already made mention of WoW, which would not be necessary on any system without XP X64 right? why not research up on that WoW on MSDN and see what lib/dll it's in...

<{POST_SNAPBACK}>

EXACTLY

Thanks, finding this file should be the best solution until we have a bullet-proof way of knowing through constants

[Celeri]

Bingo!

Found something very interesting. Unless I'm seriously wrong the information on this page should facilitate identification.

Obviously it's always possible for someone to make false positives but if I verify multiple conditions the only way to really fool my detection would be to ... read my source ehehehe

Keep you posted when my code is done - it might eventually be useful to someone

[seandisanti]

Bingo!

Found something very interesting. Unless I'm seriously wrong the information on this page should facilitate identification.

Obviously it's always possible for someone to make false positives but if I verify multiple conditions the only way to really fool my detection would be to ... read my source ehehehe

Keep you posted when my code is done - it might eventually be useful to someone

<{POST_SNAPBACK}>

why would someone WANT to generate a false positive to make your program run in a way that their computer apparently wouldn't be able to handle or understand?

[jpm]

Try the last beta .67. I add a @ProcessorArch macro to handle this problem.

I didn't add it in @OSType because there is 2 versions of 64-bit one with different binary/action possible on it.

I stay with how Windows works internally and report the difference with this new macro.

[Celeri]

Try the last beta .67. I add a @ProcessorArch macro to handle this problem.

I didn't add it in @OSType because there is 2 versions of 64-bit one with different binary/action possible on it.

I stay with how Windows works internally and report the difference with this new macro.

<{POST_SNAPBACK}>

Allright, I'll check it out ... as soon as I can get the bloody betas to install properly

Et merci encore!

Edited August 14, 2005 by Celeri