Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

objShell.Run issues...

- - - - -

  • Please log in to reply
44 replies to this topic

#26
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,796 posts
  • OS:none specified
  • Country: Country Flag
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

Posted Image



How to remove advertisement from MSFN

#27
Geej

Geej

    Senior Member

  • Member
  • PipPipPipPip
  • 635 posts
  • OS:XP Pro x86
  • Country: Country Flag
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, 05 March 2013 - 06:35 AM.


#28
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,796 posts
  • OS:none specified
  • Country: Country Flag
::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

Posted Image


#29
gunsmokingman

gunsmokingman

    MSFN Master

  • Super Moderator
  • 2,418 posts
  • OS:none specified
  • Country: Country Flag
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?


Attached File  Return_x86.png   48.28KB   11 downloads

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.


GunSmokingMan



#30
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,796 posts
  • OS:none specified
  • Country: Country Flag

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, 05 March 2013 - 03:16 PM.

Posted Image


#31
Geej

Geej

    Senior Member

  • Member
  • PipPipPipPip
  • 635 posts
  • OS:XP Pro x86
  • Country: Country Flag
Since David Wang post caption is "HOWTO: Detect Process Bitness"
and bphlpt also quoted from his post it is "The logic that I use from a program to detect whether the OS is 32bit or 64bit looks like this:"
So here we have a conflict of information from his post.

However, MSDN post is that PROCESSOR_ARCHITEW6432 is an environment variable use in 'WOW64 Implementation Details (Windows)'
Here is another quote ss64.com where he quoted David Wang post too. (But look at the title: it is 32 bit or 64 bit process detection)

Hence the batch file is really a process bitness check, not OS bitness.

Just to lighten this discussion, MS also provide an article how to determine whether a computer is running a 32-bit version or 64-bit version of the Windows operating system.
The best part of it is in the 'Next Steps'. (Call support if unsure, LOL)

Regards

#32
gunsmokingman

gunsmokingman

    MSFN Master

  • Super Moderator
  • 2,418 posts
  • OS:none specified
  • Country: Country Flag
Truthfully I was expecting the AMD64 to be returned.

I added a couple more line to get CPU ID and X6432, I was expecting that my CPU ID would be the same'.
Attached File  Return_x86_1.png   51.42KB   13 downloadsAttached File  x64Return.png   92.48KB   9 downloads

I also tested on my x64 adding Wscript.Path, my Scripting App is 32 bit
Attached File  x86AppScrpitPath.png   100.55KB   8 downloads


X6432 this variable the only constant thing about it is value of Nothing, so it totally useless in a VBS environment.
Here is a full list of Technet Environment Variables


Here is my theory on a 32 bit OS the CPU is in x86 mode any will not run any 64 bit apps, on 64 bit OS you are running
in x64 bit mode period. Individual process can exists in either 32 or 64 bit architecture on 64 bit OS.

I would like to see someone install a x86 Os on to a x64 CPU and keep it at 64 bit and have more than 4 Gb of ram. This
does not include using any type of virtual machine


GunSmokingMan



#33
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,796 posts
  • OS:none specified
  • Country: Country Flag

Here is my theory on a 32 bit OS the CPU is in x86 mode any will not run any 64 bit apps, on 64 bit OS you are running
in x64 bit mode period. Individual process can exists in either 32 or 64 bit architecture on 64 bit OS.


EXACTLY!!!

Cheers and Regards

Posted Image


#34
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,796 posts
  • OS:none specified
  • Country: Country Flag

...
So here we have a conflict of information from his post.
...
Hence the batch file is really a process bitness check, not OS bitness.
...
Just to lighten this discussion, MS also provide an article how to determine whether a computer is running a 32-bit version or 64-bit version of the Windows operating system.
The best part of it is in the 'Next Steps'. (Call support if unsure, LOL)


I appreciate you trying to lighten the mood. But I don't think there is a conflict of information in David Wang's blog. I'll stand by what was as posted as the "heading" of the code snippet itself. The result of the code snippet indicates the OS bitness. The value of %PROCESSOR_ARCHITECTURE% by itself is an indicator of process bitness..

Cheers and Regards

Edited by bphlpt, 05 March 2013 - 08:45 PM.

Posted Image


#35
gunsmokingman

gunsmokingman

    MSFN Master

  • Super Moderator
  • 2,418 posts
  • OS:none specified
  • Country: Country Flag
1:\ PROCESSOR_ARCHITECTURE is more than enough to determine if the OS is x86 or x64
2:\ W6432 does not work in VBS, any code posted in Cmd I tried always got more? on every line
3:\ PROCESSOR_ARCHITECTURE is not enough to determine if a individual process is x86 or x64
4:\ There Win32_Processor that has a way to determine OS Bitness, AddressWidth


GunSmokingMan



#36
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,796 posts
  • OS:none specified
  • Country: Country Flag
Since you insist on proof:

Spoiler



I made a very simple html file with the following (Don't laugh, I'm not much of a script or HTML coder):

<!DOCTYPE html>
<html>
<head>
<script language="javascript">
function myFunction()
{
var wshell = new ActiveXObject("WScript.Shell");
proc_arch = wshell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%");
proc_arch6432 = wshell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITEW6432%");
alert("PROCESSOR_ARCHITECTURE=["+proc_arch+"]\nPROCESSOR_ARCHITEW6432=["+proc_arch6432+"]");
}
</script>
</head>
<body>

<input type="button" onclick="myFunction()" value="Show bitness">

</body>
</html>

Here is the relevant info from System Information:

OS Name                            Microsoft Windows 7 Ultimate
Version                            6.1.7601 Service Pack 1 Build 7601
System Type                        x64-based PC
Processor                          AMD TX(tm)-6100 Six-Core Processor, 3300 MHz, 3 Core(s), 6 Logical Processor(s)
Installes Physical Memory (RAM)    16.0 GB



In the image above:

* On the top is shown the code (test.html)
* On the bottom left is an instance of 32-bit IE9 v9.0.8112.16421 - Update Versions: 9.0.13 (KB2792100)
* On the bottom right is an instance of 64-bit IE9 v9.0.8112.16421 64-bit Edition - Update Versions: 9.0.13 (KB2792100)

I opened the exact same test.html code in a window of each browser. As you can see:

In the 32-bit browser:

%PROCESSOR_ARCHITECTURE% = x86
%PROCESSOR_ARCHITEW6432% = AMD64


In the 64-bit browser:

%PROCESSOR_ARCHITECTURE% = AMD64
%PROCESSOR_ARCHITEW6432% = %PROCESSOR_ARCHITEW6432% [meaning it's value is undefined]


So, to address your previous conclusions,

1:\ PROCESSOR_ARCHITECTURE is more than enough to determine if the OS is x86 or x64 -- FALSE
2:\ W6432 does not work in VBS, any code posted in Cmd I tried always got more? on every line -- It works fine in Javascript, surely there is a way in VBS, unless maybe VBS always runs in 64-bit mode if possible?
3:\ PROCESSOR_ARCHITECTURE is not enough to determine if a individual process is x86 or x64 -- FALSE, or it sure seems like that to me
4:\ There Win32_Processor that has a way to determine OS Bitness, AddressWidth -- From what you've shown me I can't argue with that.

I never said there weren't other ways to determine OS bitness. But you kept saying "my" way was wrong, wouldn't work, and wasn't necessary. I hope I've proven my point. If not, I really don't know what else you want as proof.

Cheers and Regards

Posted Image


#37
Geej

Geej

    Senior Member

  • Member
  • PipPipPipPip
  • 635 posts
  • OS:XP Pro x86
  • Country: Country Flag
bphlpt is right in David Wang's case. I realise I got it wrong.

Base on bphlpt's post #10 detection logic and also Yzöwl's post #18 batch logic,
and using GSM post #11 code but slighly modify, I think the vbscript should look like this:

Dim Act :Set Act = CreateObject("Wscript.Shell") 
Dim SysVar : Set SysVar = Act.Environment("System") 
If SysVar("PROCESSOR_ARCHITECTURE") = "AMD64" OR SysVar("PROCESSOR_ARCHITEW6432") = "AMD64" Then 
   WScript.Echo "x64 OS bit" 
else
   WScript.Echo "x32 OS bit" 
End if


#38
gunsmokingman

gunsmokingman

    MSFN Master

  • Super Moderator
  • 2,418 posts
  • OS:none specified
  • Country: Country Flag
1:\ Wow trying to put words into my mouth. :rolleyes: Please show me anywhere in this thread where I used the code you
posted, and said the results are always correct. :w00t:

2;\
Dim Act :Set Act = CreateObject("Wscript.Shell")
Dim SysVar : Set SysVar = Act.Environment("System")

Now lets get this correct when I mention PROCESSOR_ARCHITECTURE it in the above context. Show me anywhere in this
thread where I posted second rated code that you produced for your test and got the correct results, they are correct you just
do not understand the context. Do you know what environment ExpandEnvironmentStrings access?
ExpandEnvironmentStrings Method

You shown you don't read my links here a bit about what is access.

The ExpandEnvironmentStrings method expands environment variables defined in the PROCESS environment space only.


3:\ Perhaps if you had taken the time to read my link to the Environment Variables .You could of scripted something like below
and show that if you used Process will return your results in the HTA that you produced.

Dim Act :Set Act = CreateObject("Wscript.Shell")
Dim SysVar : Set SysVar = Act.Environment("System")
'Dim SysVar : Set SysVar = Act.Environment("Process")
  If Right(SysVar("PROCESSOR_ARCHITECTURE"),2) = "64" Then
    WScript.Echo "64 Bit Os   " & vbTab & SysVar("PROCESSOR_ARCHITECTURE") & _
        vbCrLf & "CPU ID      " & vbTab & SysVar("PROCESSOR_IDENTIFIER") & _
        vbCrLf & "W6432       " & vbTab & SysVar("PROCESSOR_ARCHITEW6432") & _
        vbCrLf & WScript.Path
  Else
    WScript.Echo "32 Bit Os   " & vbTab & SysVar("PROCESSOR_ARCHITECTURE") & _
        vbCrLf & "CPU ID      " & vbTab & SysVar("PROCESSOR_IDENTIFIER") & _
        vbCrLf & "W6432       " & vbTab & SysVar("PROCESSOR_ARCHITEW6432")& vbCrLf & WScript.Path
  End If

Instead you go way out of context post something that I have not reference and using innuendo that I was at fault and wrong.
Again show me where I used ExpandEnvironmentStrings in this thread and say it results are correct.

Using the above code I tested on x86 and x64 OS and it always return the correct results, see if you can produce your results
using my script and using System. I tried on 2 different OS and got always the correct results.

Just for fun I made some minor changes check the results.
Dim Act :Set Act = CreateObject("Wscript.Shell")
Dim SysVar : Set SysVar = Act.Environment("System")
'Dim SysVar : Set SysVar = Act.Environment("Process")
Dim A
  If Right(SysVar("PROCESSOR_ARCHITECTURE"),2) = "64" Then
    A = "64 Bit Os   " & vbTab & SysVar("PROCESSOR_ARCHITECTURE") & _
        vbCrLf & "CPU ID      " & vbTab & SysVar("PROCESSOR_IDENTIFIER") & _
        vbCrLf & "W6432       " & vbTab & SysVar("PROCESSOR_ARCHITEW6432") & _
        vbCrLf & WScript.Path
  Else
    A = "32 Bit Os   " & vbTab & SysVar("PROCESSOR_ARCHITECTURE") & _
        vbCrLf & "CPU ID      " & vbTab & SysVar("PROCESSOR_IDENTIFIER") & _
        vbCrLf & "W6432       " & vbTab & SysVar("PROCESSOR_ARCHITEW6432")& vbCrLf & WScript.Path
  End If 
  WScript.Echo A & vbcrlf & _
  "Test W6432 : " & Act.ExpandEnvironmentStrings("%PROCESSOR_ARCHITEW6432%")  

Results x86 app x64 OS
Attached File  MyProof.png   80.89KB   4 downloads


You can see I am getting the correct results using my scripting app output, you W6432 = AMD64
and Wscript Script Host W6432 = %PROCESSOR_ARCHITEW6432% and each show 64 Bit Os AMD64.


var Act = new ActiveXObject("WScript.Shell");
var Env = Act.Environment("System")
var a, b ="Test W6432\t" + Act.ExpandEnvironmentStrings("%PROCESSOR_ARCHITEW6432%")
var A = new Array(Env("PROCESSOR_ARCHITECTURE"),"CPU ID     \t"+
 Env("PROCESSOR_IDENTIFIER"),"W6432      \t"+Env("PROCESSOR_ARCHITEW6432"),
 "App Path   \t"+WScript.Path)
function MyTest(a){if(Right(A[0],2) == "64")
 {a ="64 Bit Os   \t"+A[0]+"\n\r"+A[1]+"\n\r"+A[2]+"\n\r"+ A[3]+"\n\r"}
 else
 {a ="32 Bit Os   \t"+A[0]+"\n\r"+A[1]+"\n\r"+A[2]+"\n\r"+ A[3]+"\n\r"}
 return a + b}
function Right(str, N){return str.substring(str.length, str.length - N);}
WScript.Echo(MyTest(a))

Same script in Jscript returns the same results
Attached File  JsProof.png   106.9KB   6 downloads

Now in these two scripts it really proves one thing and that is how wrong you are.


bphlpt is right in David Wang's case. I realise I got it wrong.

Base on bphlpt's post #10 detection logic and also Yzöwl's post #18 batch logic,
and using GSM post #11 code but slighly modify, I think the vbscript should look like this:

Dim Act :Set Act = CreateObject("Wscript.Shell") 
Dim SysVar : Set SysVar = Act.Environment("System") 
If SysVar("PROCESSOR_ARCHITECTURE") = "AMD64" OR SysVar("PROCESSOR_ARCHITEW6432") = "AMD64" Then 
   WScript.Echo "x64 OS bit" 
else
   WScript.Echo "x32 OS bit" 
End if

Not really the SysVar("PROCESSOR_ARCHITEW6432") return nothing in either script


GunSmokingMan



#39
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,796 posts
  • OS:none specified
  • Country: Country Flag
I think I realize now that GSM and I have been talking about slightly different things. He is the scripting master after all, as my poor attempts show with my "second rated code", while I come more from a CMD batch scripting background. It seems that he is able to take advantage of abilities via VBScript or Jscript that I did not realize you could do. I did not realize that you could get the value of an Environment Variable at the SYSTEM level, no matter what process you currently were in, if I understand things correctly. This is a completely foreign concept of course to a CMD batch script programmer who only has access to one %PROCESSOR_ARCHITECTURE% variable, for example, the one for the process that he is in. Even after reading his referenced links I still had to reread them a couple of times, stare at his code for a while, and work it through. I'm still learning and I guess that was the new thing I was meant to learn today.

So while I stand by the detection logic I posted in post #10, or Yzöwl's post #18, or Geej's post #37 as the safest logic to use for any script language, (CMD batch, VBScript, or JScript), that is able to run from any process on any Windows OS, (at least XP+), and accurately determine the OS bitness, I also agree that if you are indeed able to to read the Environment Variables at the SYSTEM level, then %PROCESSOR_ARCHITECTURE% alone seems to be just as accurate to determine OS bitness. In this regard GSM was right and I was wrong. I humbly ask his forgiveness for doubting him and I hope we are still friends with no hard feelings.

Cheers and Regards

Posted Image


#40
gunsmokingman

gunsmokingman

    MSFN Master

  • Super Moderator
  • 2,418 posts
  • OS:none specified
  • Country: Country Flag
bphlpt any Cmd prompt code must of been correct or Yzöwl would of said something

Your hta was correct, retrieving the correct information, it just in VBS JS Environments there more information to
access than Cmd, that where the confusion sets in. As you see there are a couple of Environments, and I have not
tested them all and only these two Process and System and they return different results depending on what
Environments it was being processed by. See you, learned something new from all this.


GunSmokingMan



#41
Geej

Geej

    Senior Member

  • Member
  • PipPipPipPip
  • 635 posts
  • OS:XP Pro x86
  • Country: Country Flag
Sorry if my code is wrong.
I was just trying to relate the cmd logic directly into vbscript when I look harder at the cmd code.

Seems like Obj.AddressWidth method is much easier in vbscript. (in Post #20)

vbscript is not something I look or consider scripting as my first choice of language, also there are always so much to learn...

Cheers

#42
bphlpt

bphlpt

    MSFN Addict

  • Member
  • PipPipPipPipPipPipPip
  • 1,796 posts
  • OS:none specified
  • Country: Country Flag
I guess this will show how both GSM and I can get the same result with different methods:

Spoiler

Same arrangement as last time. My revised "second rated code" :):

<!DOCTYPE html>
<html>
<head>
<script language="javascript">
function myFunction()
{
var Act = new ActiveXObject("WScript.Shell");
var proc_archP = Act.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%");
var proc_arch6432P = Act.ExpandEnvironmentStrings("%PROCESSOR_ARCHITEW6432%");
var SEnv = Act.Environment("System");
var proc_archS = SEnv("PROCESSOR_ARCHITECTURE");
var proc_arch6432S = SEnv("PROCESSOR_ARCHITEW6432");
alert("Process\nPROCESSOR_ARCHITECTURE=["+proc_archP+"]\nPROCESSOR_ARCHITEW6432=["+proc_arch6432P+"]\n\nSystem\nPROCESSOR_ARCHITECTURE=["+proc_archS+"]\nPROCESSOR_ARCHITEW6432=["+proc_arch6432S+"]");
}
</script>
</head>
<body>

<input type="button" onclick="myFunction()" value="Show bitness">

</body>
</html>
Note that now I get the values of %PROCESSOR_ARCHITECTURE% and %PROCESSOR_ARCHITEW6432% at both the process and the system level.

32-bit IE9 is still on the bottom left and 64-bit IE9 is still on the bottom right.

So to get the OS bitness you can use the same logic that I have advocated all along, testing the values of both %PROCESSOR_ARCHITECTURE% and %PROCESSOR_ARCHITEW6432%, using either the process or the system level variables will give the same result, or you can just check the value of only the SYSTEM %PROCESSOR_ARCHITECTURE%, if you are smart enough to know that you can do that. AFAIK, you can't do the latter via CMD batch script.

Geej, I don't think the code you posted in post #37 is "wrong". I think it will work correctly, it's just that since you were testing the SYSTEM level variables, you really didn't need to test them both. Testing only %PROCESSOR_ARCHITECTURE% should give the same result.

Cheers and Regards

Edited by bphlpt, 07 March 2013 - 03:37 AM.

Posted Image


#43
Yzöwl

Yzöwl

    Wise Owl

  • Super Moderator
  • 4,530 posts
  • OS:Windows 7 x64
  • Country: Country Flag

Donator

Seems like Obj.AddressWidth method is much easier in vbscript. (in Post #20)

vbscript is not something I look or consider scripting as my first choice of language, also there are always so much to learn...


How difficult is the single line batch/comand using WMIC I posted in post 21?

#44
gunsmokingman

gunsmokingman

    MSFN Master

  • Super Moderator
  • 2,418 posts
  • OS:none specified
  • Country: Country Flag
It not second rated now you are using the correct object for the tasks. You could use ExpandEnvironmentStrings to
get the w6432, it uses the process environment. My only critique is instead of alert it might of been nicer to have
it display the information in the HTA.

Example
<!--
 Hta And Script By Gunsmokingman Aka Jake1Eye
 This code is property of Gunsmokingman and Or Jake1Eye and you must have his permission to use.
 This is only posted as example code and meant only to used as such.
-->
<TITLE>Test</TITLE>
<STYLE type="text/css">
Body
{
Padding-Top:5pt;Padding-Bottom:1pt;Margin:1pt;
Font-Size:10.25pt;Font-Weight:Bold;
Font-Family:Segoe Ui, Arial,Tahoma,Comic Sans MS;
Color:Black;BackGround-Color:#EFE9E3;
Text-Align:Center;Vertical-Align:Top;
}
DIV
{
Font-Size:9.25pt;Font-Weight:Bold;Color:#008181;
Font-Family:Segoe Ui, Arial,Tahoma,Comic Sans MS;
width:250;
}
</STYLE>
<script LANGUAGE='JScript'>
//-> Resize And Place In Approx center
window.resizeTo(327,150)
window.moveTo(screen.availWidth/2-(327/2),screen.availHeight/2-(150/2))
//-> Onload
window.onload=function(){
var Act = new ActiveXObject("WScript.Shell");
var Env = Act.Environment("System")
var W6432 = Act.ExpandEnvironmentStrings("%PROCESSOR_ARCHITEW6432%");
Tx1.innerHTML= '<TABLE>PROCESSOR_ARCHITECTURE=['+Env("PROCESSOR_ARCHITECTURE")+']<TABLE>'+
'<TABLE>PROCESSOR_ARCHITEW6432=['+W6432+']<TABLE>'}
</SCRIPT>
<BODY><DIV ID='Tx1'>  </DIV></BODY>
Attached File  SampleHta.png   101.64KB   6 downloads


GunSmokingMan



#45
Geej

Geej

    Senior Member

  • Member
  • PipPipPipPip
  • 635 posts
  • OS:XP Pro x86
  • Country: Country Flag

Seems like Obj.AddressWidth method is much easier in vbscript. (in Post #20)

vbscript is not something I look or consider scripting as my first choice of language, also there are always so much to learn...


How difficult is the single line batch/comand using WMIC I posted in post 21?

Certainly not hard at all. I always have this "WOW' or "awesome" feeling for a single line code.
I wonder why David Wang comes up with such a confusing method using batch. He certainly confuse me :)




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN