1 |
On Thu, Jul 19, 2012 at 9:43 AM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
2 |
> On Thu, 19 Jul 2012 16:31:42 +0300 |
3 |
> Nikos Chantziaras <realnc@×××××.com> wrote: |
4 |
> |
5 |
>> On 19/07/12 16:03, Michael Mol wrote: |
6 |
>> > On Thu, Jul 19, 2012 at 8:55 AM, Nikos Chantziaras |
7 |
>> > <realnc@×××××.com> wrote: |
8 |
>> >> Interesting that Wine aims to do the WOW64 thing. That's |
9 |
>> >> certainly news to me :-) |
10 |
>> > |
11 |
>> > Not really surprising. There's an IsWow64Process() in the Windows |
12 |
>> > API to allow processes to detect the nature of the environment |
13 |
>> > they're running on, since sometimes that's something you need to |
14 |
>> > know. :) |
15 |
>> |
16 |
>> WOW64 relies on 32-bit libraries to do it's job though. It's well |
17 |
>> known that 32-bit code cannot link against 64-bit libraries. If |
18 |
>> building a 64-bit only version of Wine (since you cannot build any |
19 |
>> 32-bit code on non-multilib Gentoo), the question arises on how Wine |
20 |
>> is doing it. |
21 |
>> |
22 |
>> |
23 |
> |
24 |
> Stupid question incoming: |
25 |
> |
26 |
> What's the WOW in WOW64? |
27 |
> |
28 |
> The more I read it as World of Warcraft the more I see that it doesn't |
29 |
> actually fit :-) |
30 |
|
31 |
WOW64 is Windows On Windows 64-bit. It's how 32-bit Windows |
32 |
applications run on 64-bit Windows. |
33 |
|
34 |
By and large, the way 32-bit and 64-bit applications and libraries can |
35 |
communicate with each other are very limited. 64-bit programs can't |
36 |
load 32-bit libraries, and vice versa. Some environment variables |
37 |
containing path information are switched out depending on if the |
38 |
program is 32-bit or 64-bit. Accesses to some registry paths are |
39 |
shunted to one place or another, depending on if the program is 32-bit |
40 |
or 64-bit. |
41 |
For system libraries, 64-bit windows provides both 32-bit and 64-bit |
42 |
versions of supported libraries, rather like multilib environments on |
43 |
Linux. |
44 |
|
45 |
In essence, if you get 64-bit Windows, you're getting two copies of |
46 |
Windows, a 64-bit version and a 32-bit version, and the kernel shunts |
47 |
32-bit programs into the 32-bit version while maintaining a reasonably |
48 |
high degree of interoperability; it's not a complete sandbox. |
49 |
|
50 |
32-bit and 64-bit processes can still communicate with each other. |
51 |
mmap()'d files still work the same way, as the filesystem paths don't |
52 |
change. Named objects such as pipes, events, mutexes...all of those |
53 |
are handled by the kernel, which has mapping code to allow 32-bit and |
54 |
64-bit processes to independently gain handles on the same named |
55 |
objects. (Subject to security attributes and restrictions, of course.) |
56 |
|
57 |
But, yeah. That's "Windows, on Windows 64-bit", or WOW64. |
58 |
|
59 |
(P.S. For the Horde!) |
60 |
-- |
61 |
:wq |