Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Is batch file called from 32 or 64 cmd.exe?
5,116 views
Skip to first unread message
Gabor Grothendieck
Jun 10, 2012, 7:41:09 PM6/10/12
to
Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this without using external utilities, if possible. Thanks.
John Gray
Jun 11, 2012, 1:25:34 AM6/11/12
to
On Monday, June 11, 2012 12:41:09 AM UTC+1, Gabor Grothendieck wrote:
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this without using external utilities, if possible. Thanks.
The answer appears to be No, since the two CMD.EXE files are identical.
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this without using external utilities, if possible. Thanks.
Directory of c:\Windows\System32
20/11/2010 05:17 302,592 cmd.exe
Directory of c:\Windows\SysWOW64
20/11/2010 05:17 302,592 cmd.exe
Comparing files SYSTEM32\cmd.exe and SYSWOW64\CMD.EXE
FC: no differences encountered
My only caveat is the existence of another CMD.EXE:
Directory of c:\Windows\winsxs\amd64_microsoft-windows-commandprompt_31bf3856ad364e35_6.1.7601.1754_none_e932cc2c30fc13b0
20/11/2010 06:24 345,088 cmd.exe
foxidrive
Jun 11, 2012, 1:39:04 AM6/11/12
to
set>file32.txt
and a
set>file64.txt
and compare them too.
--
Mic
Gabor Grothendieck
Jun 11, 2012, 8:30:43 PM6/11/12
to
On Monday, June 11, 2012 1:39:04 AM UTC-4, foxidrive wrote:
>
> do a
> set>file32.txt
> and a
> set>file64.txt
>
> and compare them too.
>
Thanks for the idea. I have now tried something along those lines (comparing the number of environment variables so that no temp files need be created) but it always gives 32 as the result. Do you have any idea of what is wrong? Thanks.
>
> do a
> set>file32.txt
> and a
> set>file64.txt
>
> and compare them too.
>
:: whicharch.bat
@echo off
setlocal
set cmd32=%windir%\System32\cmd.exe
set lineCount=0
set lineCount32=0
if exist %cmd32% for /f %%r in ('%cmd32% /c set') do set /a lineCount32+=1
:: don't need next lines
:: set cmd64=%windir%\WoW64\cmd.exe
:: set lineCount64=0
:: if exist %cmd64% for /f %%r in ('%cmd64% /c set') do set /a lineCount64+=1
for /f %%r in ('set') do set /a lineCount+=1
set R_ARCH=64
if %lineCount%==%lineCount32% set R_ARCH=32
set R_ARCH
foxidrive
Jun 11, 2012, 11:20:21 PM6/11/12
to
On Tuesday 12/06/2012 10:30, Gabor Grothendieck wrote:
> On Monday, June 11, 2012 1:39:04 AM UTC-4, foxidrive wrote:
>>
>> do a
>> set>file32.txt
>> and a
>> set>file64.txt
>>
>> and compare them too.
>>
> Thanks for the idea.
Do they actually have a significant difference? Is there an environment variable that exists in one and not in the other?
> On Monday, June 11, 2012 1:39:04 AM UTC-4, foxidrive wrote:
>>
>> do a
>> set>file32.txt
>> and a
>> set>file64.txt
>>
>> and compare them too.
>>
> Thanks for the idea.
--
Mic
Frank P. Westlake
Jun 12, 2012, 10:14:57 AM6/12/12
to
On 2012-06-10 16:41, Gabor Grothendieck wrote:
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ?
Environment variables are unreliable because they can be removed or
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ?
changed. The token "%CMDCMDLINE%" is a little more reliable but will
only sometimes tell you where your CMD came from.
This question was asked here before and I don't think a solution was
found then either. Maybe one of us will know a way around the need to
make this determination if you explain why you want to know.
Frank
foxidrive
Jun 12, 2012, 10:26:56 AM6/12/12
to
On Wednesday 13/06/2012 00:14, Frank P. Westlake wrote:
> On 2012-06-10 16:41, Gabor Grothendieck wrote:
>> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ?
>
> Environment variables are unreliable because they can be removed or
> changed.
System variables are set by Windows when the CMD prompt is opened. In that regard those ones are reliable.
> On 2012-06-10 16:41, Gabor Grothendieck wrote:
>> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ?
>
> Environment variables are unreliable because they can be removed or
> changed.
> The token "%CMDCMDLINE%" is a little more reliable but will
> only sometimes tell you where your CMD came from.
>
> This question was asked here before and I don't think a solution was
> found then either. Maybe one of us will know a way around the need to
> make this determination if you explain why you want to know.
--
Mic
Frank P. Westlake
Jun 12, 2012, 11:06:33 AM6/12/12
to
On 2012-06-12 07:26, foxidrive wrote:
> System variables are set by Windows when the CMD prompt is opened. In that regard those ones are reliable.
C:\w>set PROCESSOR_ARCHITECTURE
> System variables are set by Windows when the CMD prompt is opened. In that regard those ones are reliable.
PROCESSOR_ARCHITECTURE=AMD64
C:\w>set PROCESSOR_ARCHITECTURE=
C:\w>set PROCESSOR_ARCHITECTURE
Environment variable PROCESSOR_ARCHITECTURE not defined
Any application run now will not have the variable
"PROCESSOR_ARCHITECTURE" defined, so it is unreliable. It is normal on
my system for the environment to be purged of variables I don't want there.
Frank
foxidrive
Jun 12, 2012, 11:24:11 AM6/12/12
to
Anyone that sits there at a command prompt clearing system variables deserves what they get! LOL
--
Mic
frank.w...@gmail.com
Jun 12, 2012, 11:49:03 AM6/12/12
to
From foxidrive :
He would know which CMD is being used.
>Anyone that sits there at a command prompt clearing
>system variables deserves what they get! LOL
On my system it's done automatically by script.
Frank
>As I said, Frank, "when the CMD prompt is opened" and
>this assumes that the batch file is clicked in Windows
>so it inherits the standard system variables.
If he were opening a console this thread wouldn't exist.
>this assumes that the batch file is clicked in Windows
>so it inherits the standard system variables.
He would know which CMD is being used.
>Anyone that sits there at a command prompt clearing
>system variables deserves what they get! LOL
Frank
foxidrive
Jun 12, 2012, 12:13:53 PM6/12/12
to
On Wednesday 13/06/2012 01:49, frank.w...@gmail.com wrote:
> From foxidrive :
>> As I said, Frank, "when the CMD prompt is opened" and
>> this assumes that the batch file is clicked in Windows
>> so it inherits the standard system variables.
>
> If he were opening a console this thread wouldn't exist.
> He would know which CMD is being used.
Then system variables would be intact.
> From foxidrive :
>> As I said, Frank, "when the CMD prompt is opened" and
>> this assumes that the batch file is clicked in Windows
>> so it inherits the standard system variables.
>
> If he were opening a console this thread wouldn't exist.
> He would know which CMD is being used.
>> Anyone that sits there at a command prompt clearing
>> system variables deserves what they get! LOL
>
> On my system it's done automatically by script.
Which system variables do you clear?
--
Mic
Todd Vargo
Jun 12, 2012, 4:30:48 PM6/12/12
to
the same, then what is the purpose for checking?
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
Gabor Grothendieck
Jun 12, 2012, 4:56:50 PM6/12/12
to
On Tuesday, June 12, 2012 10:14:57 AM UTC-4, Frank P. Westlake wrote:
> This question was asked here before and I don't think a solution was
> found then either. Maybe one of us will know a way around the need to
> make this determination if you explain why you want to know.
I have a batch file:
> This question was asked here before and I don't think a solution was
> found then either. Maybe one of us will know a way around the need to
> make this determination if you explain why you want to know.
http://code.google.com/p/batchfiles/source/browse/trunk/Rgui.bat
that starts R:
http://www.r-project.org/
The problem is that on 64 bit systems there can be a 32 bit and a 64 bit version of R. If there is only one R architecture on the system it uses that but if not the command can take an --arch=32 or --arch=64 switch or one can supply an environment variable SET R_ARCH=32 or SET R_ARCH=64. It assumes 32 bit if nothing else works. Nevertheless this is not really optimal.
If the architecture were not specified and there were multiple R architectures
it would be more convenient to assume that the user wanted the 32 bit version if they were using a 32 bit cmd.exe and a 64 bit version if they were using a 64 bit cmd.exe . They could still use the other methods too but this way the default would be correct a greater fraction of the time and it allows one to specify the architecture without setting anything but just by launching the appropriate cmd.exe .
JJ
Jun 12, 2012, 7:00:29 PM6/12/12
to
Gabor Grothendieck <ggroth...@gmail.com> wrote in
news:7ffeea89-2075-4321...@googlegroups.com:
> Is there some way of finding out in a batch file if it was invoked
> from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do
> this without using external utilities, if possible. Thanks.
There are differences in PROCESSOR_xxx variables:
CMD in WinXP 32-bit:
PROCESSOR_ARCHITECTURE=x86
Has no PROCESSOR_ARCHITEW6432
CMD x32 in Win7 64-bit:
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
CMD X64 in Win7 64-bit:
PROCESSOR_ARCHITECTURE=X64
Has no PROCESSOR_ARCHITEW6432
While they may be changed or deleted, why would a program do it?
They seem reliable enough.
news:7ffeea89-2075-4321...@googlegroups.com:
> Is there some way of finding out in a batch file if it was invoked
> from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do
> this without using external utilities, if possible. Thanks.
CMD in WinXP 32-bit:
PROCESSOR_ARCHITECTURE=x86
Has no PROCESSOR_ARCHITEW6432
CMD x32 in Win7 64-bit:
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
CMD X64 in Win7 64-bit:
PROCESSOR_ARCHITECTURE=X64
Has no PROCESSOR_ARCHITEW6432
While they may be changed or deleted, why would a program do it?
They seem reliable enough.
foxidrive
Jun 12, 2012, 11:27:04 PM6/12/12
to
echo "%comspec%" |find /i "system32\cmd.exe" >nul && (set R_ARCH=32) || (set R_ARCH=64)
--
Mic
frank.w...@gmail.com
Jun 13, 2012, 7:09:47 AM6/13/12
to
I think someone posted here a MicroSoft reference that
showed how to determine if
the OS is running as 32- or 64-bit. It involved checking
the output of certain configuration utilities, which one
depended on the OS. Maybe someone here remembers it.
I would use that as the primary test. If it fails for
some I would check for "PROCESSOR_ARCHITEW6432=AMD64" --
see JJ's message here.
Frank
showed how to determine if
the OS is running as 32- or 64-bit. It involved checking
the output of certain configuration utilities, which one
depended on the OS. Maybe someone here remembers it.
I would use that as the primary test. If it fails for
some I would check for "PROCESSOR_ARCHITEW6432=AMD64" --
see JJ's message here.
Frank
John Gray
Jun 13, 2012, 9:38:32 AM6/13/12
to
if defined ProgramFiles(x86) (set bits=64) else (set bits=32)
Thomas Langer
Jun 13, 2012, 10:40:54 PM6/13/12
to
in 32bit cmd.exe.
If you want to know if started in 32bit cmd.exe on 54 bit system then
you can compare contents of %programfiles% and %programfiles(x86)
variables. In 32bit session it will point to the same directory but not
in 64 bit session.
frank.w...@gmail.com
Jun 14, 2012, 7:49:50 AM6/14/12
to
>John Gray:
better. Assume that if the 64-bit files exist then it is
a 64-bit system. The variable 'windir' is more likely to
exist and cause less problems. Is there problem with
checking the file system instead of the environment?
I'm on an Android so my paths above are only guesses.
Frank
>> I use if defined ProgramFiles(x86) (set bits=64) else (set bits=32)
Maybe checking for the directory "%windir%\wow64"(?) is
better. Assume that if the 64-bit files exist then it is
a 64-bit system. The variable 'windir' is more likely to
exist and cause less problems. Is there problem with
checking the file system instead of the environment?
I'm on an Android so my paths above are only guesses.
Frank
ten.n...@virgin.net
Jun 14, 2012, 6:24:56 PM6/14/12
to
C:\Windows\System32 345,088 cmd.exe
C:\Windows\SysWOW64 302,592 cmd.exe
Additionally when you run SET on both there are differences with the
output which can be utilised:
IF "%PROGRAMFILES%"=="%PROGRAMFILES(X86)%" ECHO=64BIT CONSOLE INVOKED
or
IF DEFINED PROCESSOR_ARCHITEW6432 ECHO=64BIT CONSOLE INVOKED
Incidentally other than invoking the 64bit console yourself, your 64bit
system will by default use the 32bit "system32" executable. This behaviour
may change if the SysWOW64 location is added to %PATH%, but you'd need to
try that yourself if you wish to find out.
frank.w...@gmail.com
Jun 15, 2012, 6:31:35 AM6/15/12
to
From ten.nigriv:
On my W7/64 (one of the "Home" versions) they are the
same. On John Gray's they were the same. Maybe yours is
a 'Business' system, or supports encryption.
I think the check for which CMD had been invoked was
only a potential fallback means of determining whether
the OS is running as a 64-bit system -- it was not the
primary goal.
Does anyone see a problem with checking for
'%windir%/SysWOW64'? Could user's persissions in the
file system be a problem? Someone please give us a piece
of script which makes this test, I'm on an Android at
the moment. I think IF EXIST might be better than DIR.
Frank
>Well on my Windows 7 64bit system, both versions of
cmd.exe are different...
On my W7/64 (one of the "Home" versions) they are the
same. On John Gray's they were the same. Maybe yours is
a 'Business' system, or supports encryption.
I think the check for which CMD had been invoked was
only a potential fallback means of determining whether
the OS is running as a 64-bit system -- it was not the
primary goal.
Does anyone see a problem with checking for
'%windir%/SysWOW64'? Could user's persissions in the
file system be a problem? Someone please give us a piece
of script which makes this test, I'm on an Android at
the moment. I think IF EXIST might be better than DIR.
Frank
Vic RR Garcia
Jun 15, 2012, 12:24:11 PM6/15/12
to
On 06/15/12 06:31, frank.w...@gmail.com wrote:
> From ten.nigriv:
>> Well on my Windows 7 64bit system, both versions of
> cmd.exe are different...
>
> On my W7/64 (one of the "Home" versions) they are the same. On John
> Gray's they were the same. Maybe yours is a 'Business' system, or
> supports encryption.
On Ultimate/64, depending on the patch level, you can find at least 4
> From ten.nigriv:
>> Well on my Windows 7 64bit system, both versions of
> cmd.exe are different...
>
> On my W7/64 (one of the "Home" versions) they are the same. On John
> Gray's they were the same. Maybe yours is a 'Business' system, or
> supports encryption.
different versions, 2 old ones, 2 new ones:
C:\Windows\System32
11/20/10 09:24 345,088 cmd.exe
C:\Windows\SysWOW64
11/20/10 08:17 302,592 cmd.exe
C:\Windows\winsxs\amd64_microsoft-windows-
commandprompt_31bf3856ad364e35_6.1.7600.16385_none_e701b864340d9016
07/13/09 21:39 344,576 cmd.exe
C:\Windows\winsxs\wow64_microsoft-windows-
commandprompt_31bf3856ad364e35_6.1.7600.16385_none_f15662b6686e5211
07/13/09 21:14 301,568 cmd.exe
Todd Vargo
Jun 15, 2012, 4:47:33 PM6/15/12
to
and follow the links which the OP provided on June 12, the goal AFAICS,
is to launch a particular GUI app (32bit or 64bit) from a batch based on
which cmd processor the batch is running in. If this is incorrect, the
OP would need to explain it. I could ask OP a dozen questions to get to
the primary goal but it seems everyone is more focused on solving the
subject line.
Todd Vargo
Jun 15, 2012, 5:03:43 PM6/15/12
to
On 6/15/2012 12:24 PM, Vic RR Garcia wrote:
> On 06/15/12 06:31, frank.w...@gmail.com wrote:
>> From ten.nigriv:
>>> Well on my Windows 7 64bit system, both versions of
>> cmd.exe are different...
>>
>> On my W7/64 (one of the "Home" versions) they are the same. On John
>> Gray's they were the same. Maybe yours is a 'Business' system, or
>> supports encryption.
>
> On Ultimate/64, depending on the patch level, you can find at least 4
> different versions, 2 old ones, 2 new ones:
>
> C:\Windows\System32
> 11/20/10 09:24 345,088 cmd.exe
>
> C:\Windows\SysWOW64
> 11/20/10 08:17 302,592 cmd.exe
>
> C:\Windows\winsxs\amd64_microsoft-windows-
> commandprompt_31bf3856ad364e35_6.1.7600.16385_none_e701b864340d9016
> 07/13/09 21:39 344,576 cmd.exe
>
> C:\Windows\winsxs\wow64_microsoft-windows-
> commandprompt_31bf3856ad364e35_6.1.7600.16385_none_f15662b6686e5211
> 07/13/09 21:14 301,568 cmd.exe
Does VER report differently on each?
> On 06/15/12 06:31, frank.w...@gmail.com wrote:
>> From ten.nigriv:
>>> Well on my Windows 7 64bit system, both versions of
>> cmd.exe are different...
>>
>> On my W7/64 (one of the "Home" versions) they are the same. On John
>> Gray's they were the same. Maybe yours is a 'Business' system, or
>> supports encryption.
>
> On Ultimate/64, depending on the patch level, you can find at least 4
> different versions, 2 old ones, 2 new ones:
>
> C:\Windows\System32
> 11/20/10 09:24 345,088 cmd.exe
>
> C:\Windows\SysWOW64
> 11/20/10 08:17 302,592 cmd.exe
>
> C:\Windows\winsxs\amd64_microsoft-windows-
> commandprompt_31bf3856ad364e35_6.1.7600.16385_none_e701b864340d9016
> 07/13/09 21:39 344,576 cmd.exe
>
> C:\Windows\winsxs\wow64_microsoft-windows-
> commandprompt_31bf3856ad364e35_6.1.7600.16385_none_f15662b6686e5211
> 07/13/09 21:14 301,568 cmd.exe
Vic RR Garcia
Jun 15, 2012, 8:24:58 PM6/15/12
to
values, no difference at all.
Frank P. Westlake
Jun 16, 2012, 10:01:45 AM6/16/12
to
On 2012-06-12 09:13, foxidrive wrote:
> On Wednesday 13/06/2012 01:49, frank.w...@gmail.com wrote:
>> From foxidrive :
>>> As I said, Frank, "when the CMD prompt is opened" and
>>> this assumes that the batch file is clicked in Windows
>>> so it inherits the standard system variables.
>>
>> If he were opening a console this thread wouldn't exist.
>> He would know which CMD is being used.
>
> Then system variables would be intact.
As I said, not on necessarily. The "PROCESSOR_*" variables are in the
> On Wednesday 13/06/2012 01:49, frank.w...@gmail.com wrote:
>> From foxidrive :
>>> As I said, Frank, "when the CMD prompt is opened" and
>>> this assumes that the batch file is clicked in Windows
>>> so it inherits the standard system variables.
>>
>> If he were opening a console this thread wouldn't exist.
>> He would know which CMD is being used.
>
> Then system variables would be intact.
Registry machine environment which I customize, and which anyone else
may easily customize.
Frank
Frank P. Westlake
Jun 16, 2012, 10:11:38 AM6/16/12
to
On 2012-06-12 13:56, Gabor Grothendieck wrote:
> The problem is that on 64 bit systems there can be a 32 bit and a 64 bit version of R.
> If there is only one R architecture on the system it uses that but if
not the command
> can take an --arch=32 or --arch=64 switch or one can supply an
environment variable
> SET R_ARCH=32 or SET R_ARCH=64. It assumes 32 bit if nothing else works.
Since there haven't been any objections to using the file system I think
> The problem is that on 64 bit systems there can be a 32 bit and a 64 bit version of R.
> If there is only one R architecture on the system it uses that but if
not the command
> can take an --arch=32 or --arch=64 switch or one can supply an
environment variable
> SET R_ARCH=32 or SET R_ARCH=64. It assumes 32 bit if nothing else works.
this should be a solid solution:
If EXIST "%SystemRoot%\SysWOW64" (
Set "R_ARCH=64"
) Else (
Set "R_ARCH=32"
)
Frank
Thomas Langer
Jun 16, 2012, 3:52:28 PM6/16/12
to
Your approach is very good, but there is one crucial point - you
interchanged the directories mentioned.
The 64bit part of a 64bit-version of Windows resides in
%systemroot%\system32.
However, the 32bit part resides in %systemroot%\SysWOW64 (stands for
Windows on Windows64). Funny, isn´t it?
And so a 64bit OS will by default use a 64bit console, too.
You can veryfiy this by using the task manager, because the task manager
flags 32bit processes.
The following snippet is independent from operating system and patch
level used (tested with XPx64 and W7x64). It informs you whether the
operating system and the console´s process is 32 or 64bit.
@echo off
REM declaring variables and assigning default values
set BitSystem=32
set BitConsole=32
REM test if running on a 64bit system
If defined programfiles(x86) set BitSystem=64
REM test if running in 32bit console on 64bit system
If %BitSystem% EQU 64 If NOT "%ProgramFiles%"=="%ProgramFiles(x86)%" set
BitConsole=64
echo running on %BitSystem%bit system in %BitConsole%bit console...
Regards
--
Thomas Langer
bitte nur der NG antworten - please answer to newsgroup only
für direkte Mails Spam weglassen - for direct mails omit spam
frank.w...@gmail.com
Jun 18, 2012, 6:49:30 AM6/18/12
to
From Thomas Langer :
keep looking for a test which does not use the
environment.
Frank
>The 64bit part of a 64bit-version of Windows resides in
>%systemroot%\system32.
>However, the 32bit part resides in %systemroot%\SysWOW64
>(stands for Windows on Windows64).
Thank you very much for that valuable information. I'll
>%systemroot%\system32.
>However, the 32bit part resides in %systemroot%\SysWOW64
>(stands for Windows on Windows64).
keep looking for a test which does not use the
environment.
Frank
frank.w...@gmail.com
Jun 18, 2012, 7:27:36 AM6/18/12
to
From Thomas Langer :
"%systemdrive%\Program Files(x86)"? I have only W7/64.
Frank
>@echo off
>REM declaring variables and assigning default values
>set BitSystem=32
>set BitConsole=32
>REM test if running on a 64bit system
>If defined programfiles(x86) set BitSystem=64
>REM test if running in 32bit console on 64bit system
>If %BitSystem% EQU 64 If NOT
>"%ProgramFiles%"=="%ProgramFiles(x86)%" set
>BitConsole=64
>echo running on %BitSystem%bit system in %BitConsole%bit
>console...
Can you construct a similar test using
>REM declaring variables and assigning default values
>set BitSystem=32
>set BitConsole=32
>REM test if running on a 64bit system
>If defined programfiles(x86) set BitSystem=64
>REM test if running in 32bit console on 64bit system
>If %BitSystem% EQU 64 If NOT
>"%ProgramFiles%"=="%ProgramFiles(x86)%" set
>BitConsole=64
>echo running on %BitSystem%bit system in %BitConsole%bit
>console...
"%systemdrive%\Program Files(x86)"? I have only W7/64.
Frank
Zaidy036
Jun 18, 2012, 11:34:20 AM6/18/12
to
On 6/10/2012 7:41 PM, Gabor Grothendieck wrote:
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this without using external utilities, if possible. Thanks.
Task Manager shows following depending on which is running
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this without using external utilities, if possible. Thanks.
C:\Windows\System32\cmd.exe
C:\Windows\SystemWOW64\cmd.exe
so should be able to use a combination of TASKLIST and/or FINDSTR
to see which one is running
--
Zaidy036
Thomas Langer
Jun 18, 2012, 7:54:22 PM6/18/12
to
I assume that you are looking for a solution that does not depend on
environment variables.
Therefore I will use an other approach, but this approach is more
complex and has some disadvantages in comparison with my solution
depending on system environment.
If a 32bit cmd.exe is running and a 64bit cmd.exe, too, the following
code can not detect, in which of both cmd.exes the script is running. If
there is a manually created directory %systemdrive%\program files(x86)
the script will return a wrong result. At last the result seems to be
wrong if cmd.exe is invoked by a lnk-file being renamed.
Because of this disadvantages you are strongly recommended to use my
first solution.
The following snippet uses tasklist.exe to list all cmd.exe processes.
It tests, whether the string syswow64 is part of the fully qualified
file name of one of these running cmd.exes. If so one of the running
cmd.exe processes must be a 32bit process on a 64bit system.
The code containes very long lines. All lines that do not begin with two
blanks are accidentally wrapped.
@echo off
set BitSystem=32
set BitConsole=64
if exist "%systemdrive%\program files (x86)" set BitSystem=64
if not exist "%systemdrive%\program files (x86)" set BitConsole=32
if %BitSystem% EQU 64 for /f "tokens=10 delims= " %%i in ('tasklist
/v /fo table /fi "imagename eq cmd.exe" /nh ^| findstr /b /i
/c:cmd.exe') do @(echo %%i | findstr /i /c:syswow64 && set BitConsole=32)
echo running on %BitSystem%bit system in %BitConsole%bit console...
If this does not fit your needs please explain more detailed.
frank.w...@gmail.com
Jun 19, 2012, 7:00:32 AM6/19/12
to
From Zaidy036 :
>Task Manager shows following depending on which is
>running
> C:\Windows\System32\cmd.exe
> C:\Windows\SystemWOW64\cmd.exe
On my 64-bit system there are always several CMD.EXE
instances. It is probable that none will ever have the
the SysWOW64 path.
Frank
>Task Manager shows following depending on which is
>running
> C:\Windows\System32\cmd.exe
> C:\Windows\SystemWOW64\cmd.exe
instances. It is probable that none will ever have the
the SysWOW64 path.
Frank
frank.w...@gmail.com
Jun 19, 2012, 7:07:47 AM6/19/12
to
I think my previous message here responds to this
sufficiently, but I'll add that it is probably more
likely that someone will delete variables then to create
a '%systemdrive%\Program Files (x86)' or a
'%systemdrive%\Windows\sysWOW64'.
I normally write e-mail on an Android so the paths I
show here and in other messages may be in error.
Frank
sufficiently, but I'll add that it is probably more
likely that someone will delete variables then to create
a '%systemdrive%\Program Files (x86)' or a
'%systemdrive%\Windows\sysWOW64'.
I normally write e-mail on an Android so the paths I
show here and in other messages may be in error.
Frank
bisa...@gmail.com
Apr 20, 2018, 7:59:58 AM4/20/18
to
On Monday, June 11, 2012 at 7:41:09 AM UTC+8, Gabor Grothendieck wrote:
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this without using external utilities, if possible. Thanks.
I use the following command on my 64bit version of windows 10 (havn't tested on 32bit operating system), *check_process_bits.bat*:
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this without using external utilities, if possible. Thanks.
```bat
IF EXIST "%windir%\Sysnative\cmd.exe" (ECHO proc32_on_win64) ELSE ECHO proc64_on_win64 or proc32_on_win32
```
* Hold `Win+R` to open 32bit "%windir%\SysWOW64\cmd.exe", copy and paste the above commandline or run *check_process_bits.bat*, it outputs: *proc32_on_win64*
* Hold `Win+R` to open 64bit "%windir%\System32\cmd.exe", copy and paste the above commandline or run *check_process_bits.bat*, it outputs: *proc64_on_win64 or proc32_on_win32*
Considering the 32-bit OS, we can use [batch file to check 64bit or 32bit OS](https://stackoverflow.com/questions/12322308/batch-file-to-check-64bit-or-32bit-os#24590583)
> ```bat
> @echo OFF
>
> reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find /i "x86" > NUL && set OS=32BIT || set OS=64BIT
>
> if %OS%==32BIT echo This is a 32bit operating system
> if %OS%==64BIT echo This is a 64bit operating system
> ```
Auric__
Apr 20, 2018, 1:36:08 PM4/20/18
to
bisanfang wrote:
> On Monday, June 11, 2012 at 7:41:09 AM UTC+8, Gabor Grothendieck wrote:
^^^^^^^^^^^^^
> On Monday, June 11, 2012 at 7:41:09 AM UTC+8, Gabor Grothendieck wrote:
***SIX YEARS AGO.***
>> Is there some way of finding out in a batch file if it was invoked from
>> a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this
>> without using external utilities, if possible. Thanks.
>
> I use the following command on my 64bit version of windows 10 (havn't
> tested on 32bit operating system), *check_process_bits.bat*:
>
> ```bat
> IF EXIST "%windir%\Sysnative\cmd.exe" (ECHO proc32_on_win64) ELSE ECHO
> proc64_on_win64 or proc32_on_win32 ```
My Win10x86 install does *not* have that directory, nor does my Win7x64
system.
> Considering the 32-bit OS, we can use [batch file to check 64bit or
> 32bit OS]
> (https://stackoverflow.com/questions/12322308/batch-file-to-check-64bit-
> or-32bit-os#24590583)
>> ```bat
>> @echo OFF
>>
>> reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find
>> /i "x86" > NUL && set OS=32BIT || set OS=64BIT
>>
>> if %OS%==32BIT echo This is a 32bit operating system
>> if %OS%==64BIT echo This is a 64bit operating system
>> ```
Intel architectures. For example, Windows 10 has an ARM edition; how would
you deal with that?
--
The approval of the dead is meaningless.
JJ
Apr 21, 2018, 10:11:03 AM4/21/18
to
On Fri, 20 Apr 2018 17:36:07 -0000 (UTC), Auric__ wrote:
> bisanfang wrote:
>
>> On Monday, June 11, 2012 at 7:41:09 AM UTC+8, Gabor Grothendieck wrote:
> ^^^^^^^^^^^^^
>
> ***SIX YEARS AGO.***
It's GG users, after all.
> bisanfang wrote:
>
>> On Monday, June 11, 2012 at 7:41:09 AM UTC+8, Gabor Grothendieck wrote:
> ^^^^^^^^^^^^^
>
> ***SIX YEARS AGO.***
>> I use the following command on my 64bit version of windows 10 (havn't
>> tested on 32bit operating system), *check_process_bits.bat*:
>>
>> ```bat
>> IF EXIST "%windir%\Sysnative\cmd.exe" (ECHO proc32_on_win64) ELSE ECHO
>> proc64_on_win64 or proc32_on_win32 ```
> [snip]
>
> My Win10x86 install does *not* have that directory, nor does my Win7x64
> system.
Windows. It's not a physical directory and it's not enumerable.
>>> reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find
>>> /i "x86" > NUL && set OS=32BIT || set OS=64BIT
>>>
>>> if %OS%==32BIT echo This is a 32bit operating system
>>> if %OS%==64BIT echo This is a 64bit operating system
>>> ```
>
> The only problem I see is the (rare?) case where Windows is running on non-
> Intel architectures. For example, Windows 10 has an ARM edition; how would
> you deal with that?
CMD (or any application) is 32-bit or 64-bit.
If the CPU need to be checked for something else, the CPU ID would be one of
these:
- Intel64 = Intel [x86-64; 64-bit]
- AMD64 = AMD [x86-64; 64-bit]
- VIA64 = Via Nano [x86-64; 64-bit]
- x86 = AMD/Intel [x86; 32-bit]
- ARM = ARM Cortex [32-bit]
- EM64T = Intel Itanium [IA64; 64-bit]
On 64-bit Windows XP, Intel x86-64 is detected as EM64T. Because there's no
Intel x86-64 at the time Windows XP x64 is released.
I don't know about 64-bit ARM CPU ID.
JJ
Apr 21, 2018, 11:06:32 AM4/21/18
to
On Sat, 21 Apr 2018 21:12:26 +0700, JJ wrote:
>
> On 64-bit Windows XP, Intel x86-64 is detected as EM64T. Because there's no
> Intel x86-64 at the time Windows XP x64 is released.
This can be checked using the VendorIdentifier registry value. e.g.
>
> On 64-bit Windows XP, Intel x86-64 is detected as EM64T. Because there's no
> Intel x86-64 at the time Windows XP x64 is released.
@echo off
setlocal
set "cmd=reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" ^| find "VendorIdentifier""
set id=
for /f "tokens=3" %%A in ('%cmd%') do set "id=%%A"
echo Vendor ID: %id%
if "%id%" == "GenuineIntel" (
set brand=Intel
) else if "%id%" == "AuthenticAMD" (
set brand=AMD
) else if "%id%" == "VIA VIA VIA " (
set brand=VIA
) else (
set brand=(Unknown)
)
echo Brand: %brand%
Auric__
Apr 21, 2018, 11:11:01 PM4/21/18
to
JJ wrote:
> On Fri, 20 Apr 2018 17:36:07 -0000 (UTC), Auric__ wrote:
>> bisanfang wrote:
>>
>>> On Monday, June 11, 2012 at 7:41:09 AM UTC+8, Gabor Grothendieck
>>> wrote:
>> ^^^^^^^^^^^^^
>>
>> ***SIX YEARS AGO.***
>
> It's GG users, after all.
I know. You can see me calling them out on this bullshit all over the place.
> On Fri, 20 Apr 2018 17:36:07 -0000 (UTC), Auric__ wrote:
>> bisanfang wrote:
>>
>>> On Monday, June 11, 2012 at 7:41:09 AM UTC+8, Gabor Grothendieck
>>> wrote:
>> ^^^^^^^^^^^^^
>>
>> ***SIX YEARS AGO.***
>
> It's GG users, after all.
>>> I use the following command on my 64bit version of windows 10 (havn't
>>> tested on 32bit operating system), *check_process_bits.bat*:
>>>
>>> ```bat
>>> IF EXIST "%windir%\Sysnative\cmd.exe" (ECHO proc32_on_win64) ELSE ECHO
>>> proc64_on_win64 or proc32_on_win32 ```
>> [snip]
>>
>> My Win10x86 install does *not* have that directory, nor does my Win7x64
>> system.
>
> It's a pseudo directory which only exists on 32-bit applications in a
> 64-bit Windows. It's not a physical directory and it's not enumerable.
--
Condense fact from the vapor of nuance.
Tom Del Rosso
Apr 22, 2018, 8:47:56 AM4/22/18
to
JJ wrote:
> On Fri, 20 Apr 2018 17:36:07 -0000 (UTC), Auric__ wrote:
>> bisanfang wrote:
>>
>>> On Monday, June 11, 2012 at 7:41:09 AM UTC+8, Gabor Grothendieck
>>> wrote:
>> ^^^^^^^^^^^^^
>>
>> ***SIX YEARS AGO.***
>
> It's GG users, after all.
But I'm glad "bisanfang" posted because...
> On Fri, 20 Apr 2018 17:36:07 -0000 (UTC), Auric__ wrote:
>> bisanfang wrote:
>>
>>> On Monday, June 11, 2012 at 7:41:09 AM UTC+8, Gabor Grothendieck
>>> wrote:
>> ^^^^^^^^^^^^^
>>
>> ***SIX YEARS AGO.***
>
> It's GG users, after all.
>>> I use the following command on my 64bit version of windows 10
>>> (havn't tested on 32bit operating system), *check_process_bits.bat*:
>>>
>>> ```bat
>>> IF EXIST "%windir%\Sysnative\cmd.exe" (ECHO proc32_on_win64) ELSE
>>> ECHO proc64_on_win64 or proc32_on_win32 ```
>> [snip]
>>
>> My Win10x86 install does *not* have that directory, nor does my
>> Win7x64 system.
>
> It's a pseudo directory which only exists on 32-bit applications in a
> 64-bit Windows. It's not a physical directory and it's not enumerable.
Tom Del Rosso
Apr 22, 2018, 8:52:13 AM4/22/18
to
Auric__ wrote:
>
> Interesting. My 32-bit file manager doesn't see it at all.
If it's interesting to you too then why complain? Suppose bisanfang had
>
> Interesting. My 32-bit file manager doesn't see it at all.
started a new thread instead of replying to an old one. Then he would
have taught us something and it would be ok. It makes no difference
that it was a reply.
Auric__
Apr 22, 2018, 11:09:35 AM4/22/18
to
an old thread that I complain. Half of such posts tend to be along the lines
of "me too", or are effectively duplicating a reply from the original thread.
I have seen Google Groupies reply to threads that are over 20 years old, FFS!
I seriously doubt the original posters are still waiting around for answers.
Google Groupies tend to not have any concept of netiquette. I've said, more
than once, that this is The September That Never Ended Part II:
https://en.wikipedia.org/wiki/Eternal_September
https://en.wikipedia.org/wiki/Google_Groups#Criticism
--
I'm glad your genetic code will die with you.
Tom Del Rosso
Apr 22, 2018, 11:59:17 AM4/22/18
to
Auric__ wrote:
> Tom Del Rosso wrote:
>
>> Auric__ wrote:
>>>
>>> Interesting. My 32-bit file manager doesn't see it at all.
>>
>> If it's interesting to you too then why complain? Suppose bisanfang
>> had started a new thread instead of replying to an old one. Then he
>> would have taught us something and it would be ok. It makes no
>> difference that it was a reply.
>
> It doesn't matter if you learned something new. It's *because* he
> replied to an old thread that I complain. Half of such posts tend to
> be along the lines of "me too", or are effectively duplicating a
> reply from the original thread. I have seen Google Groupies reply to
> threads that are over 20 years old, FFS! I seriously doubt the
> original posters are still waiting around for answers.
Right, of course, but in this case it wasn't "me too." I'd also get
> Tom Del Rosso wrote:
>
>> Auric__ wrote:
>>>
>>> Interesting. My 32-bit file manager doesn't see it at all.
>>
>> If it's interesting to you too then why complain? Suppose bisanfang
>> had started a new thread instead of replying to an old one. Then he
>> would have taught us something and it would be ok. It makes no
>> difference that it was a reply.
>
> It doesn't matter if you learned something new. It's *because* he
> replied to an old thread that I complain. Half of such posts tend to
> be along the lines of "me too", or are effectively duplicating a
> reply from the original thread. I have seen Google Groupies reply to
> threads that are over 20 years old, FFS! I seriously doubt the
> original posters are still waiting around for answers.
annoyed at the content-free reply.
I'm grateful he contributed knowledge here. It's a good group, but it
seems like there is an informative thread twice a month.
Auric__
Apr 22, 2018, 1:34:50 PM4/22/18
to
he dropped the schedule to monthly around 5 years ago and stopped posting it
entirely maybe a year later. It was around that time that things started to
dry up.
The FAQ is still available on Prof. Salmi's site:
https://www.netikka.net/tsneti/info/tscmd.php
Almost any batch problem you can think of is covered in the FAQ.
Unfortunately, it doesn't cover things like "don't revive ancient threads".
--
Intelligence is alcohol soluble.
npocmaka
Apr 23, 2018, 11:07:49 AM4/23/18
to
JJ
Apr 24, 2018, 11:51:43 AM4/24/18
to
On Mon, 23 Apr 2018 08:07:47 -0700 (PDT), npocmaka wrote:
>
> to check if it is the C:\Windows\SysWOW64\cmd.exe you can check the %__APPDIR__% environment variable.
Nice. This one including the %__CD__% variable, are undocumented feature of
>
> to check if it is the C:\Windows\SysWOW64\cmd.exe you can check the %__APPDIR__% environment variable.
Windows - which is handled by NTDLL.DLL. It's not mentioned in MSDN.
markov...@gmail.com
Jun 8, 2018, 3:14:47 AM6/8/18
to
понедељак, 11. јун 2012. 01.41.09 UTC+2, Gabor Grothendieck је написао/ла:
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this without using external utilities, if possible. Thanks.
.cmd extension is for 64-bit.
> Is there some way of finding out in a batch file if it was invoked from a 32 bit or 64 bit cmd.exe ? My preference is to be able to do this without using external utilities, if possible. Thanks.
.bat extension is for 32-bit.
Auric__
Jun 8, 2018, 3:56:49 AM6/8/18
to
instead.
.cmd comes from OS/2, a 32-bit system. 32-bit Windows has no problem running
them.
.bat comes from DOS, a 16-bit system. 64-bit Windows has no problem running
them.
--
This hurts my brain.
B00ze
Jun 8, 2018, 11:39:50 PM6/8/18
to
On 2018-06-08 03:56, Auric__ <not.m...@email.address> wrote:
> markovicb599 wrote:
>
>> .cmd extension is for 64-bit.
>> .bat extension is for 32-bit.
>
> [BZZT] Oh, so sorry, wrong answer. Thanks for playing, try our home game
> instead.
>
> running them.
Aren't we supposed to use CMD ever since WinNT? I use CMD for anything
that runs in Windows, rather than in real DOS (where I use BAT.)
According to the following, there ARE differences between using CMD/BAT
for file-extension even tho you run both with cmd.exe:
https://stackoverflow.com/questions/148968/windows-batch-files-bat-vs-cmd
Regards,
--
! _\|/_ Sylvain / B00...@hotmail.com
! (o o) Member:David-Suzuki-Fdn/EFF/Red+Cross/SPCA/Planetary-Society
oO-( )-Oo You think I care which way you face? -O'Brien
> markovicb599 wrote:
>
>> .cmd extension is for 64-bit.
>> .bat extension is for 32-bit.
>
> [BZZT] Oh, so sorry, wrong answer. Thanks for playing, try our home game
> instead.
>
> cmd comes from OS/2, a 32-bit system. 32-bit Windows has no problem running
> them. bat comes from DOS, a 16-bit system. 64-bit Windows has no problem
> running them.
Aren't we supposed to use CMD ever since WinNT? I use CMD for anything
that runs in Windows, rather than in real DOS (where I use BAT.)
According to the following, there ARE differences between using CMD/BAT
for file-extension even tho you run both with cmd.exe:
https://stackoverflow.com/questions/148968/windows-batch-files-bat-vs-cmd
Regards,
--
! _\|/_ Sylvain / B00...@hotmail.com
! (o o) Member:David-Suzuki-Fdn/EFF/Red+Cross/SPCA/Planetary-Society
oO-( )-Oo You think I care which way you face? -O'Brien
0 new messages