First Post - all things x64
Welcome to my stinkin' blog. I just wanted a place to dump interesting & useful blobs of information about what I've been doing for the past 4 or 5 years of my life @ work: x64.
My name is Kevin Frei, and I've been a developer on the x64 (aka AMD64, EM64T, and x86-64) compiler since it's inception. I'm originally from Pocatello, ID, I really don't miss it one bit. Except maybe the cost of housing :-)
So, here's the stuff I wanted to make public. It's all generally about how to successfully use Windows XP Pro for x64 (and Win2003 Server for x64) in a normal day-to-day environment. I'll probably toss out useful compiler/code gen things in the future, but for right now, this is it:
So, without further ado, here we go:
- %windir%\syswow64\cmd.exe is your best friend
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'
- Use Internet Explorer (32 bit)
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...
- 'Program Files (x86)' can cause lots of problems with scripts
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...
- Detecting that you're running under WOW64 from 32 bit scripts
PROCESSOR_ARCHITEW6432 is set to the real processor architecture when you're running syswow64\cmd.exe
- When is system32 not system32?
When it's been mapped to syswow64! If you're running under WoW64, your actual system32 directory isn't visible - it's a duplicate of syswow64. Magic! Sometimes this can be little confusing, though.
- How can I see stuff in the real system32 from a 32 bit process?
From a 64 bit CMD, linkd [somewhere] %windir%\system32
Now, from 32 bit apps, you can see the contents of the real system32 [with all it’s 64 bit images] from a 32 bit process, from the [somewhere] directory. I don't know if linkd.exe is available outside of MSFT. I'm sure there's some other way to accomplish this...
Comments
Anonymous
November 05, 2004
linkd is for setting up a (hard?)link to a directory? Believe it is available in some resource kit...
But junction[1] should do quite the same job...
[1] http://www.sysinternals.com/ntw2k/source/misc.shtml#junctionAnonymous
July 28, 2006
Linkd actually creates soft-links equivalent to UNIX Symbolic links (ln -s <target> <name>) aka "Junction Points" in MS terms.
Junction Points are seen in a "DIR" list and ...interestingly enough... extensively used in Active Directory SYSVOL.
Deleting a Junction Point does not delete the target as opposed to hard-links, which delete all cross-linked instances.
It is supported starting with NTFS version 5 (Windows 2000 and higher) and comes with Windows 2000 and 2003 server Resourcekit (rktools.exe).
Windows NT 4 NTFS (NTFS 4) does only support softlinks thorugh 3rd party tools.Anonymous
February 06, 2007
So when the '%windir%syswow64cmd.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.Anonymous
March 13, 2007
You can install 32 bit applications with very few problems, but the kernel is still 64 bit, so you can't use any drivers.Anonymous
October 29, 2007
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.Anonymous
October 30, 2007
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.Anonymous
November 06, 2007
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 thanksAnonymous
November 06, 2007
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...Anonymous
November 06, 2007
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.Anonymous
November 06, 2007
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