When you launch the 32 bit command prompt, PROCESSOR_ARCHITECTURE is set to x86, ProgramFiles is set to "c:\program files (x86)", and suddenly lots of things 'just work'
The 64 bit internet explorer works great, unless you need to run activeX controls, which are present on far too many web pages out there. Of course, the 64 bit version of IE is kind of nice, simply because there's no more irritating Flash advertisements, and no obnoxious addins. I've actually started using Avant Browser, and have found that it's quite pleasant, though always 32 bit...
If you have scripts that use %ProgramFiles%, this can act a little weird, due to parentheses parsing problems. You can work your way around it by doing this from inside your script:
for %%D in ("%ProgramFiles%") do set ProgramFiles=%%~sD
This makes the variable use short pathnames: no more parenthese or spaces. It's actually a useful trick in general to get spaces & parentheses out of environment variables, in general. Maybe I'll fix mine fixer script and put it up here in the future...
PROCESSOR_ARCHITEW6432 is set to the real processor architecture when you're running syswow64\cmd.exe
From a 64 bit CMD, linkd [somewhere] %windir%\system32
So when the '%windir%\syswow64\cmd.exe' is executed the entire system turn to 32-bit. Does that mean I can install 32-bit applications and drivers without a problem.
Because At some point I was not able to install them without erroring.
You can install 32 bit applications with very few problems, but the kernel is still 64 bit, so you can't use any drivers.
Kevin,
The whole world at the moment is running at problems with syswow64 and 32 bit programs. Why on earth did Microsoft introduce this? Couldn't they find a more transparent way? Right now you get problems such as trying to run utilities (diskpart) from cmd32 or modifying registry entries using cscript etc...
Isn't this solution really bad?
Cheers,
George.
I believe the syswow64 redirection was designed for compatibility before usability. There was a significant (and understandable) concern that if the system weren't compatible with old code, it wouldn't catch on. Please also keep in mind this decision wasn't made for x64 Vista, or even x64 XP. It was made for the Windows 2000 'Preview' for IA64. A lot of the stuff that makes x64 what it is today is a hodge podge of stuff from both IA64 & x86, unfortunately.
Hi there, Just wondering if you would be able to answer this question for me. I was using 32bit and had a game that required me to edit the
C:/Windows/system32/drivers/etc/hosts file. I have ungraded to 64bit and done everything in the setup exactly the same and it doesn't work. Could the 64bit be causing it not to work? Do you know anyways around this?
Many thanks
What kind of edits did you have to make to get it to work under 32 bit? The network stack is quite a bit different from the 32 bit network stack...
Basically it involved setting up a fake verification server so the game would run thinking it had an authorisation code sent from the website but had actually been looped back to ask for permission from 127.0.0.1
I would then get a message in the fake verification server to say connected, but now under 64bit I don't.
If you're actually running a web server on your 64 bit system, there's a good chance you have to monkey with it to get it to like your 32 bit web service, but that's the tail end of my knowledge. Search for WOW64 IIS or something like that. BTW - E-mail works better than blog comments ;-) kfrei@microsoft.com