On Thu, 19 Jul 2012 10:06:18 -0400 Michael Mol <mike...@gmail.com> wrote:
> 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. thanks, that makes sense > > (P.S. For the Horde!) :-) -- Alan McKinnon alan.mckin...@gmail.com
