Sign in to follow this  
Followers 0
Falcor

objShell.Run issues...

45 posts in this topic

These are your words that you posted

PROCESSOR_ARCHITECTURE will be equal to "x86" even though you are running a 64-bit OS on a 64-bit processor.

I still say you are wrong the below image show the PROCESSOR_ARCHITECTURE variable is returning AMD64 in

VBS and CMD Prompt.. From you posted it should be x86.

post-5386-0-42244000-1362301812_thumb.pn

0

Share this post


Link to post
Share on other sites

Thanks for all your help, people.

I am not too worried about how the code looks until after I have gotten everything working. Once that is taken care of I will clean it up. :thumbup

On to the next problem...

0

Share this post


Link to post
Share on other sites

Detection Logic

The logic that I use from a program to detect whether the OS is 32bit or 64bit looks like this:

IF PROCESSOR_ARCHITECTURE == amd64 OR

PROCESSOR_ARCHITEW6432 == amd64 THEN

// OS is 64bit

ELSE

// OS is 32bit

END IF

Another way to test for the same thing is:

IF PROCESSOR_ARCHITECTURE == x86 AND

PROCESSOR_ARCHITEW6432 NOT DEFINED THEN

// OS is 32bit

ELSE

// OS is 64bit

END IF

Using that logic then the following should suffice:

ECHO=%PROCESSOR_ARCHITECTURE%' %PROCESSOR_ARCHITEW6432%'|FIND "64'">NUL 2>&1&&ECHO=[64bit]||ECHO=[x86]

Alternatively:

REG QUERY "HKLM\Hardware\Description\System\CentralProcessor\0" /v Identifier|FIND /I "x86"&&ECHO=[x86]||ECHO=[64bit]

0

Share this post


Link to post
Share on other sites

inf detection logic

Just right-click ChkOSbitness.inf and "install"

[Version]
Signature=$Windows NT$

[DefaultInstall]
RegisterDLLs=Start.Register

[Start.Register]
11,,rundll32.exe,,,"advpack.dll,LaunchINFSection %1%\%infname%.inf,Install"

[Install.ntx86]
RunPostSetupCommands=echo86

[Install.ntamd64]
RunPostSetupCommands=echo64

[echo86]
cmd /c echo x86 section is called & pause

[echo64]
cmd /c echo x64 section is called & pause

[Strings]
infname=ChkOSbitness

0

Share this post


Link to post
Share on other sites

Win32_Processor class (Windows)

AddressWidth

Data type: uint16

Access type: Read-only

On a 32-bit operating system, the value is 32 and on a 64-bit operating system it is 64. This property is inherited from CIM_Processor.

So this would be the most effective way of finding out if the OS is x86 or x64


Dim Wmi :Set Wmi = GetObject("winmgmts:\\.\root\CIMV2")
Dim Obj
For Each Obj In Wmi.ExecQuery("SELECT * FROM Win32_Processor")
If Obj.AddressWidth = "64" Then
MsgBox "64 Os Bit : " & Obj.AddressWidth
Else
MsgBox "32 Os Bit : " & Obj.AddressWidth
End If
Next

0

Share this post


Link to post
Share on other sites

And this from the commandline / batch

WMIC CPU GET ADDRESSWIDTH /VALUE|FIND "=64">NUL 2>&1&&ECHO=[64bit]||ECHO=[x86]

0

Share this post


Link to post
Share on other sites

GSM, I'm really not trying to argue with you.

These are your words that you posted

PROCESSOR_ARCHITECTURE will be equal to "x86" even though you are running a 64-bit OS on a 64-bit processor.

Yes I said that. But you seem to have missed the first part of the sentence:

But its value is important to check for since in that same unique circumstance that PROCESSOR_ARCHITEW6432 is defined, PROCESSOR_ARCHITECTURE will be equal to "x86" even though you are running a 64-bit OS on a 64-bit processor.

And again, I'm only quoting directly from Microsoft. My only explanation for your results is that the process that was running was a 64-bit process.

Cheers and Regards

Edited by bphlpt
0

Share this post


Link to post
Share on other sites

PROCESSOR_ARCHITECTURE6432 comes into picture only when 32-bit application is running on x64 OS.

You might find this MSDN article useful.

It describes how x64 OS handles 32-bit applications.

Running 32-bit Applications (Windows)

Also read 'WOW64 Implementation Details'. It mentions PROCESSOR_ARCHITEW6432 environment variable.

In short, PROCESSOR_ARCHITECTURE6432 is not a variable to check your OS bitness.

PROCESSOR_ARCHITECTURE6432 is (as I see it) transparent to the user as it is how the operating system handles internally 32-bit program within a x64 os.

0

Share this post


Link to post
Share on other sites

I give up. LOL I guess nobody reads or believes MS. :)

Cheers and Regards

0

Share this post


Link to post
Share on other sites

bphlpt

1:\ Posted code in wrong language, the poster wrote this in VBS

2:\ What you posted was no better than my original post.

3:\ Microsoft you keep saying that, but you have not provided any links to support what you claim.

4:\ Geej and I have posted links to support our claims.

5:\ Yzöwl provided a Cmd script, of VBS from what I read the most accurate way to get OS bit

0

Share this post


Link to post
Share on other sites

GSM

1:\ Posted code in wrong language, the poster wrote this in VBS - No argument, you are the VBS expert, not me. I just posted the logic of what is recommended to test for, a Batch script command to accomplish that, a link to another discussion about this issue, and a link to an MSDN blog - David Wang at MS - which explains the reasoning behind the recommended solution.

3:\ Microsoft you keep saying that, but you have not provided any links to support what you claim. - Link to MSDN blog was indirectly posted in post #8. The link was available in the discussion thread I linked to here. The link was given in that thread at least three times and the code was also copied from there into the thread. In case folks didn't want to read the full discussion to get the actual MSDN blog link, I then posted the actual MSDN blog link in post #10, and again above, and I'll post it yet again here for your convenience - David Wang at MS. I don't know if David is still with MS or not, but he was part of the MS IIS team for at least five years and blogged at http://blogs.msdn.com from 2004 - 2008. Then on top of that, I posted a copy of almost the entire blog post in post #10 in case people didn't even want to bother going to the MSDN site to read it for themselves. I don't know how much more I need to post to "support what I claim".

It also ends up that this same logic is implemented in the Windows Assessment and Deployment Kit (ADK) for Windows 8/WinPE 4.0. Microsoft Example in ..\Windows Kits\8.0\Assessment and Deployment Kit\Deployment Tools\DandISetEnv.cmd:


@Echo off

REM
REM Sets the PROCESSOR_ARCHITECTURE according to native platform for x86 and x64.
REM
IF /I %PROCESSOR_ARCHITECTURE%==x86 (
IF NOT "%PROCESSOR_ARCHITEW6432%"=="" (
SET PROCESSOR_ARCHITECTURE=%PROCESSOR_ARCHITEW6432%
)
) ELSE IF /I NOT %PROCESSOR_ARCHITECTURE%==amd64 (
@echo Not implemented for PROCESSOR_ARCHITECTURE of %PROCESSOR_ARCHITECTURE%.
@echo Using "%ProgramFiles%"

SET NewPath="%ProgramFiles%"

goto SetPath
)

5:\ Yzöwl provided a Cmd script, of VBS from what I read the most accurate way to get OS bit - Yzöwl posted an alternative Cmd script in post #18 that implements the same logic that David Wang recommends:

Using that logic then the following should suffice:

ECHO=%PROCESSOR_ARCHITECTURE%' %PROCESSOR_ARCHITEW6432%'|FIND "64'">NUL 2>&1&&ECHO=[64bit]||ECHO=[x86]

Ricktendo, vmanda, mr_smartepants, OnePiece, 5eraph, gora, dumpydooby, ELiTE, and others were all involved in the discussion referenced above. You, and the OP, are welcome to use whatever code works best for you. I just don't know why you keep saying that I am wrong. I did not create the code.

Cheers and Regards

0

Share this post


Link to post
Share on other sites

Why are we checking the value of %PROCESSOR_ARCHITEW6432% in a batch file?

Does it affect the OS bitness result?

My common sense tells me since %PROCESSOR_ARCHITEW6432%'s value is dynamic, it makes no diffenece checking this value that will affect the result of OS bitness.

But OS bitness is static. Will this dynmanic value affect a static value?

Shouldn't we be checking something that has a static value and consistent throughout the lifetime while the OS is up & running?

Just another thought...

Edited by Geej
0

Share this post


Link to post
Share on other sites

::sigh:

Geej, The reason that is given in the links I referenced is because %PROCESSOR_ARCHITECTURE%, which you would think is static, gives the "wrong" value IF you are running a 32-bit process in your 64-bit OS. In that particular case, %PROCESSOR_ARCHITECTURE% will indicate x86. According to the references, the quickest, easiest, most reliable way to verify your OS bitness at any time no matter what kind of process you are running, is to look at the two values, %PROCESSOR_ARCHITECTURE% and %PROCESSOR_ARCHITEW6432%, together. As Yzöwl and I have both shown, this is quite easy to do via batch Cmd script. As has been pointed out in other posts in this thread, there are other methods through VBS, wmic, etc to also check other values for OS bitness. I am not saying they are wrong, or slower, or more inaccurate. I am only reporting what I have read and I have seen verified.

Cheers and Regards

0

Share this post


Link to post
Share on other sites

This was a quote from one of your another discussion link.

Ah, but %PROCESSOR_ARCHITECTURE% only detects the arch of the CPU. What if you have a 32-bit OS on a 64-bit CPU?

post-5386-0-62579600-1362507966_thumb.pn

I tested the script from my Win 7 desktop from a CD based 32 bit OS and as you can see it return the x86 or 32 bit,

I have this CPU Type and it a 64 bit CPU.

Let get this straight, this is the caption from David Wang HOWTO: Detect Process Bitness and not

HOW TO Detect OS Bitness.

0

Share this post


Link to post
Share on other sites
Let get this straight, this is the caption from David Wang HOWTO: Detect Process Bitness

Yes, that is the title of the blog. Thank you for looking at it.

As you just proved, even though your actual physical hardware processor chip in your system is a 64-bit processor, (From what you posted it is, correct?) , if you run a 32-bit OS, or process, on it, at the time that 32-bit process is running, the System variable %PROCESSOR_ARCHITECTURE% will indicate it is (at least acting as) a 32-bit processor as far as the software is concerned. The code you posted indicates that you commented out all reference to %PROCESSOR_ARCHITEW6432% so that it is not involved in this test at all, correct? The value of %PROCESSOR_ARCHITECTURE% alone is what triggered your message box, correct? Which is why %PROCESSOR_ARCHITECTURE% alone is not a sufficient test for OS bitness. It also requires testing the value, or at least the existence, of %PROCESSOR_ARCHITEW6432%. The variable %PROCESSOR_ARCHITECTURE% by itself really is only an indicator of process bitness and not OS bitness. (In a 32-bit OS, they are one and the same, of course.) And as you have seen, it has nothing at all to do with the CPU's hardware bitness.

Regardless of the title of the blog, the heading above the code is:

The logic that I use from a program to detect whether the OS is 32bit or 64bit looks like this:


IF PROCESSOR_ARCHITECTURE == amd64 OR
PROCESSOR_ARCHITEW6432 == amd64 THEN
// OS is 64bit
ELSE
// OS is 32bit
END IF

Another way to test for the same thing is:

IF PROCESSOR_ARCHITECTURE == x86 AND
PROCESSOR_ARCHITEW6432 NOT DEFINED THEN
// OS is 32bit
ELSE
// OS is 64bit
END IF

Cheers and Regards

Edited by bphlpt
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.