On Thu, Jul 19, 2012 at 9:43 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > On Thu, 19 Jul 2012 16:31:42 +0300 > Nikos Chantziaras <rea...@gmail.com> wrote: > >> On 19/07/12 16:03, Michael Mol wrote: >> > On Thu, Jul 19, 2012 at 8:55 AM, Nikos Chantziaras >> > <rea...@gmail.com> wrote: >> >> Interesting that Wine aims to do the WOW64 thing. That's >> >> certainly news to me :-) >> > >> > Not really surprising. There's an IsWow64Process() in the Windows >> > API to allow processes to detect the nature of the environment >> > they're running on, since sometimes that's something you need to >> > know. :) >> >> WOW64 relies on 32-bit libraries to do it's job though. It's well >> known that 32-bit code cannot link against 64-bit libraries. If >> building a 64-bit only version of Wine (since you cannot build any >> 32-bit code on non-multilib Gentoo), the question arises on how Wine >> is doing it. >> >> > > Stupid question incoming: > > What's the WOW in WOW64? > > The more I read it as World of Warcraft the more I see that it doesn't > actually fit :-)
WOW64 is Windows On Windows 64-bit. It's how 32-bit Windows applications run on 64-bit Windows. By and large, the way 32-bit and 64-bit applications and libraries can communicate with each other are very limited. 64-bit programs can't load 32-bit libraries, and vice versa. Some environment variables containing path information are switched out depending on if the program is 32-bit or 64-bit. Accesses to some registry paths are shunted to one place or another, depending on if the program is 32-bit or 64-bit. For system libraries, 64-bit windows provides both 32-bit and 64-bit versions of supported libraries, rather like multilib environments on Linux. In essence, if you get 64-bit Windows, you're getting two copies of Windows, a 64-bit version and a 32-bit version, and the kernel shunts 32-bit programs into the 32-bit version while maintaining a reasonably high degree of interoperability; it's not a complete sandbox. 32-bit and 64-bit processes can still communicate with each other. mmap()'d files still work the same way, as the filesystem paths don't change. Named objects such as pipes, events, mutexes...all of those are handled by the kernel, which has mapping code to allow 32-bit and 64-bit processes to independently gain handles on the same named objects. (Subject to security attributes and restrictions, of course.) But, yeah. That's "Windows, on Windows 64-bit", or WOW64. (P.S. For the Horde!) -- :wq
