WOW64 Question

[Zen]

I'm wondering,...have any of you guys ever had problems running a 32-bit MASM app on a 64-bit Intel processor and 64-bit Windows version ???
For reference, here is: Running 32-bit Applications, MSDN

[Gunther]

Hi Zen,

if the 32-bit application is well written and doesn't use some undocumented features, there's no problem.

Gunther

[BlueMR2]

No problems so far...

[hutch--]

Not that I have seen, all of my MASM stuff runs on Win7 64 OK, my basic compliers run fine and to be honest I have not tried anything out with VC2003 to see what it does. I would imagine it works OK. Its been an interesting comparison, 64 bit does some things faster but others slower, 64 bit is the future but it will be a while coming.

I just installed the Unix subsystem on Win7, all 255 meg of it and I managed to find the base directory, probably what the Unix guys call "root" and  and tree behind it but I have yet to digest how to get it going. It seems you can run the command line utilities from CMD.EXE but I have run out of puff for the evening so I will play with it later.

[Zen]

Hmmm,...
Most everything I've read in programmer blogs about the WOW64 compatibility has been good,...almost flawless performance,...

[Siekmanski]

Yes, i had some problems with my mp3 code when i switched from XP 32 bit to win8 64 bit.
I had to change some bad coded pointer assignment.

[Zen]

Here is a quick overview of the WOW64 emulator: 64-Bit Windows Part 11: Windows On Windows 64
...And, an interesting blog entry here: What's the Difference Between the Wow64 and Native x86 Versions of a DLL?

The reason I asked the question in the first place is that I have been having problems with a 32-bit COM application that I am running on Windows Seven (Intel 64-bit processor). Here is a blog that addresses the issue (sort, of): Accessing 32-bit DLLs from 64-bit Code

...And, yes,...I've been having pointer problems, although the COM interfaces initialize correctly,...
The whole alignment issue still mystifies me,...and, I think it always will,...

[Siekmanski]

This is also something to be aware of.....

You can only access a COM object from a Windows application the object has been successfully initialized.
The COM API function CoInitialize()must be called for each thread that is going to access a COM object before any COM interface calls are made,
and the complementary call CoUninitialize() must be performed before the thread exits (see MSDN reference).
This rule must be strictly respected if the main process calls to the original 32-bit DLL are multi-threaded.

[jj2007]

There is a known problem with the registry and a wrong windows.inc constant.

[Zen]

JOCHEN,
I have read blogs that describe minor problems with the WOW64 emulator,...the most serious of which is a Thread Context bug.
...I found a pdf version of Windows Internals, Sixth Edition on the Internet,...which has a 4-page section describing the WOW64 subsystem,...
...It can be found here: Windows Internals, Sixth Edition, 2012,...it's only 4 pages, but makes interesting reading,...

System Calls
    Wow64 hooks all the code paths where 32-bit code would transition to the native 64-bit system or when the native system needs to call into 32-bit user-mode code. During process creation, the process manager maps into the process address space the native 64-bit Ntdll.dll, as well as the 32-bit Ntdll.dll for Wow64 processes. When the loader initialization is called, it calls the Wow64 initialization code inside Wow64.dll. Wow64 then sets up the startup context required by the 32-bit Ntdll, switches the CPU mode to 32-bits, and starts executing the 32-bit loader. From this point onward, execution continues as if the process is running on a native 32-bit system.
    Special 32-bit versions of Ntdll.dll, User32.dll, and Gdi32.dll are located in the \Windows\Syswow64 folder (as well as certain other DLLs that perform interprocess communication, such as Rpcrt4.dll). These call into Wow64 rather than issuing the native 32-bit system call instruction. Wow64 transitions to native 64-bit mode, captures the parameters associated with the system call (converting 32-bit pointers to 64-bit pointers), and issues the corresponding native 64-bit system call. When the native system call returns, Wow64 converts any output parameters if necessary from 64-bit to 32-bit formats before returning to 32-bit mode.
Exception Dispatching
    Wow64 hooks exception dispatching through Ntdll's KiUserExceptionDispatcher. Whenever the 64-bit kernel is about to dispatch an exception to a Wow64 process, Wow64 captures the native exception  and context record in user mode and then prepares a 32-bit exception and context record and dispatches it the same way the native 32-bit kernel would.
Restrictions
Wow64 does not support the execution of 16-bit applications (this is supported on 32-bit versions of Windows) or the loading of 32-bit kernel-mode device drivers (they must be ported to native 64-bits). Wow64 processes can load only 32-bit DLLs and can't load native 64-bit DLLs. Likewise, native 64-bit processes can't load 32-bit DLLs. The one exception is the ability to load resource or data-only DLLs
cross-architecture, which is allowed because those DLLs contain only data, not code. In addition to the above, due to page size differences, Wow64 on IA64 systems does not support the ReadFileScatter, WriteFileGather, GetWriteWatch, AVX registers, XSAVE, and AWE functions. Also, hardware acceleration through DirectX is not available. (Software emulation is provided for Wow64 processes.)

[jj2007]

Also, make sure not to get hit by Microsoft's latest update causing a BSOD ;-)

[Zen]

...Just to be annoying,...I found this: Raymond Chen Blog Entry, On 64-Bit Windows, 32-Bit Programs Run In An Emulation Layer.

..What I like about Raymond Chen is: he's smarter than QWORD, and funnier than DAVE !!!

[jj2007]

...Just to be annoying,...I found this: Raymond Chen Blog Entry, On 64-Bit Windows, 32-Bit Programs Run In An Emulation Layer.

Read the comments, too. This blog post is rather confused ::)

[sinsi]

Read the comments, too. This blog post is rather confused ::)

The blog is straightforward, the comments are...ignorant. I guess that's how you get when a compiler looks after you 
A Win32 program shouldn't care if Windows is 32- or 64-bit, shit just works.

It's when you get tricky programs that want access to the "other" registry/filesystem that things get complicated.
That's probably why MS gave in and wrote a few functions to get around redirection/virtualization.

[Gunther]

Hi sinsi,

The blog is straightforward, the comments are...ignorant. I guess that's how you get when a compiler looks after you 
A Win32 program shouldn't care if Windows is 32- or 64-bit, shit just works.

that's right. In some cases it could be necessary to use the 64-bit API. But that's no problem.

Gunther