Command Prompt Windows 7 64bit

[Mantrid-Drone]

I've been meaning to ask about this for some time but as it was not a particular 'problem' I've never bothered until now.

When you launch Command Prompt (CMD), using Win7 64bit, by default it goes to the Users directory. That's annoying enough but even with full administrator rights you can not use certain systems tools, like system file checker (SFC), unless you launch CMD using run as administrator. The way I do it is to use a desktop shortcut created with elevated privileges.

But what I'm asking about is why in either case does CMD on a Win7 64bit system by default use the Windows\system32\cmd.exe and not Windows\SysWOW64\cmd.exe?

The reason I ask this is complicated but I wanted to be able to launch CMD 64bit but there doesn't appear to be any way of doing that short of direct from the Windows folder itself. It begs the question why is it there but no mechanism for the user to launch it?

Additionally there is another problem: whilst it launches OK as is if you try to run it as administrator, as I want to do, using any of the methods I know, including creating a shortcut with elevated privileges as before, it only ever launches the System 32\cmd.exe.

Why? Is there a solution because I've researched this and I have not been able to find any explanation let alone a way that works in getting the SysWOW64\cmd.exe to run with admin rights?

 

[mikeymikec]

Here's something hilarious I learnt recently:

64-bit binaries are in the system32 folder, and 32-bit binaries are in the syswow64 folder. If you want to verify this, fire up Process Explorer (a free Windows util available from the MS website), then fire up syswow64\cmd.exe, then in PE get the properties of that process up and observe the image field saying '32-bit'. system32\cmd.exe will say 64-bit in that field.

I suspect the reason is that MS wanted to ensure that by default 64-bit binaries are getting used, and a dev would have to go out of their way to force 32-bit on a 64-bit OS.

It's a very handy thing to know on Windows 7 since chkdsk.exe in system32 is the crap version that makes any system run out of RAM during a full chkdsk run from inside a normal Windows session whereas syswow64\cmd.exe will be capped at 3GB RAM and still do the job perfectly well.

 

[VirtualLarry]

Here's something hilarious I learnt recently:
64-bit binaries are in the system32 folder, and 32-bit binaries are in the syswow64 folder.

Windows is fun, isn't it?

I presume, that this was done to speed up porting of Win32 apps to Win64, because many apps hard-coded "System32" in their source code.

 

[Mantrid-Drone]

Interesting and useful information, thanks.

I have now actually resolved the problem that prompted (hah!) this thread.

Whilst I can not find any way to get SysWOW64\cmd.exe to launch except direct from the Windows folder and it is, apparently, using the System32\cmd.exe when you launch it with "Run as administrator" it does actually work for the purpose I wanted.

That was to re-register a particular 'missing' .OCX file, downloaded from MS, and installed for 64bit program use. If you used the CMD method shown, required to do that correctly, neither SysWOW64\cmd.exe (vanilla) or, as had been warned but I still tried, System32\cmd.exe (both vanilla and run as admin) worked. All three resulted in error messages.

However when I eventually bit the bullet and launched SysWOW64\cmd.exe with run as admin, despite CMD still showing, as described, C:\Windows\System32> I was surprised. It ran the command to re-register the .OCX file correctly. Most importantly the portable program that had needed this to be able to launch on a 64bit system now works perfectly.

It doesn't make the thread redundant, the fact it worked despite CMD showing C:\Windows\System32> actually adds to the mystery.

 

[mxnerd]

Interesting.

Either you launch cmd.exe from start menu or start cmd.exe from C:\Windows\SysWOW64 directory with adminstrative rights, both opened a console showing C:\Windows\system32 as the current directory.