On Thu, 19 Jul 2012 10:06:18 -0400
Michael Mol <firstname.lastname@example.org> wrote:
> On Thu, Jul 19, 2012 at 9:43 AM, Alan McKinnon
> <email@example.com> wrote:
> > On Thu, 19 Jul 2012 16:31:42 +0300
> > Nikos Chantziaras <firstname.lastname@example.org> wrote:
> >> On 19/07/12 16:03, Michael Mol wrote:
> >> > On Thu, Jul 19, 2012 at 8:55 AM, Nikos Chantziaras
> >> > <email@example.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
> 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.
thanks, that makes sense
> (P.S. For the Horde!)