Can someone check this for me on 64 bit?

[IdeasVacuum]

If you Google "detect OS bits", several debates on the subject. We don't expect the PB compiler to do anything more than define the types to match the OS + CPU, that's a reasonable assumption nowadays, so your test stands up. Yet what is the point of the SizeOf() test when the IsWow64Process test is definitive?

[luis]

If you Google "detect OS bits", several debates on the subject

That's why I asked a link to what you have read, since I don't understand your objections to this method (originating from those readings as you say) and I probably already read most of that debates at the time when I ended up writing the code above.

Yet what is the point of the SizeOf() test when the IsWow64Process test is definitive?

Uh ? Who said that ? Check the documentation of the API:

Wow64Process [out]

A pointer to a value that is set to TRUE if the process is running under WOW64. If the process is running under 32-bit Windows, the value is set to FALSE. If the process is a 64-bit application running under 64-bit Windows, the value is also set to FALSE.

So it does set the output to TRUE if the process is a 32 bit process running under a 64bit OS. This paired with the SizeOf() test make the whole check work under 32 and 64 bit for 32 and 64 bit exes.

[IdeasVacuum]

Like this:

Code: Select all

Procedure.s OSbits()
;-------------------
; Check if the OS is 32 or 64 bit.
;
 Protected Is64BitOS = 0 ; Returns 1 for 64bit, else 0.
 Protected hDLL, IsWow64Process_
 Protected sOSbits.s = "64"
 
       hDll = OpenLibrary(#PB_Any,"kernel32.dll")
    If hDll

               IsWow64Process_ = GetFunction(hDll,"IsWow64Process")

            If IsWow64Process_

                    CallFunctionFast(IsWow64Process_, GetCurrentProcess_(), @Is64BitOS)
            EndIf

            CloseLibrary(hDll)
    EndIf     

    If Not (Is64BitOS = 1) : sOSbits = "32" : EndIf

    ProcedureReturn sOSbits

EndProcedure

[luis]

OK, I give up about the link.

Like this:

No, like the one following the method I described, like the one I posted, like the one posted by the original author of this thread. Your works for 32 bit executables only, like explained in the API's doc I quoted in the post jut before yours.

The API *DOES NOT SAY* if the OS is 64 bit. It only say if the process calling the API is executed under WOW64.
Obviously a native 64 bit process is not executed under WOW64, so your proc return the wrong value when compiled to 64 bit.

If you say: "I'm interested only to 32bit exes" than ok. But considering you only need a little modification to have a general use procedure, and that this was the whole point of the thread...

[IdeasVacuum]

Luis, I'm not trying to pick an argument, this is not a competition. I'm just trying to determine the most reliable method. My logic is that only a 32bit app needs to test if the OS is 32bit or 64bit. A 64bit app does not need to test, since it will only run on 64bit.

[luis]

Luis, I'm not trying to pick an argument, this is not a competition.

I'm not engaging myself in some rampant speculation about your motivations, I'm only interested in the informations presented in the thread, let's see them again one last time.

A 64bit app does not need to test, since it will only run on 64bit.

Yes. It's really as you say. I confirm it wholeheartedly. But a program compiled for both 32 and 64 bit may require that test, unless you want two different sources for the same program (a 64 bit version who "knows" and a 32 bit version who need to ask).

You can then call one of the two functions proposed here by SFSxOI and myself, under any condition, and get the correct reply.

Hence you can store one of those away as a library function, forget about its internals, and simply use it from now on.


OR you can skip half of that test (sizeof()), and have a correct reply only if you compiled the exe to 32 bit.

OR you can check if your exe is 64 bit outside from that procedure, don't call it, and call it if the exe is 32 bit.

OR you can compile your program to 64 bit only and avoid a check at all because it will run only if the OS is 64 bit.

Take your pick.

Now about the "why" I'm replying to you ? Because I want to win a competition ? Because I like to argue since I don't have many interests in life and I'm boring myself to death every passing day ? Nope.

I replied to you because you said about the use of SizeOf(): "This is deemed unreliable at runtime (via exe) if your app is 32bit running on a 64bit OS".
I found that wrong in the context of how sizeof() was used here, and I explained sizeof() is reliable by definition, the only way to THINK it is unreliable is to use it wrongly (in the way you mentioned), probably that was what the google links were talking about but as you know I wasn't able to check them.

Then I replied to you because you said using sizeof() was unneeded (I disagreed and explained why can be useful in this context).

Then I replied to you when you asked why we need it if the API call was enough (I explained why it may not be enough).

And in the end I conceded your test is enough if you plan to compile your program only as a 32 bit exe and you cannot afford a SizeOf().

That's it. Is there something wrong with all that ? Because I don't see it.

You prefer your way ? It's fine. But I can reply if I believe your is not the best way to approach the problem (especially because later other people can read this and make wrong assumptions) or if you ask me a question. In fact I did.