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