From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.77) (envelope-from ) id 1SrrP2-0007xv-B6 for garchives@archives.gentoo.org; Thu, 19 Jul 2012 14:08:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4F60AE06C8; Thu, 19 Jul 2012 14:07:57 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id C23E4E05EB for ; Thu, 19 Jul 2012 14:06:19 +0000 (UTC) Received: by bkwj4 with SMTP id j4so2421149bkw.40 for ; Thu, 19 Jul 2012 07:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uqhKzH9c6aW08a8CVHTgEYV4cXPCS2wuxvULlAzL+3w=; b=GLAIDzXfRnSZLq1lfv4emvnSofogH72WCiVzIFRrzLe88fV2gMacMpEHAOYWPfMjdO 2svFPfxYDrML3GeWNifagWDxm6pa7rW2wNEPQVyBBw1EjLB9JwS8GnsAaQTXyXA0bgKB cxp3MQnBnzIBC+oa3pySH1G54N/SKhRHWUL0X+4dLbkk4YuFBQPk8hdWKZI0fBlfaZkc PrdNWog3lMdduw1aBHfROSlrdcxsRhFFKVJauU4HYqwT8nvdBOXr43eEYu8iTSnCmr0a SaZ32YdYaPf4LeVcleYJVCbNOH1Djpql5OHJBQPVjXEeJlKTYU4QRy0vyA2KCqMginOz OwtQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.157.156 with SMTP id b28mr1194306bkx.27.1342706778843; Thu, 19 Jul 2012 07:06:18 -0700 (PDT) Received: by 10.204.10.12 with HTTP; Thu, 19 Jul 2012 07:06:18 -0700 (PDT) In-Reply-To: <20120719154347.0598a71d@khamul.example.com> References: <3200326.C1v6ghYEo5@localhost> <20120719154347.0598a71d@khamul.example.com> Date: Thu, 19 Jul 2012 10:06:18 -0400 Message-ID: Subject: Re: [gentoo-user] Re: 32bit or 64bit From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 52ca1a30-89be-4aad-b842-cb9a224a7fdc X-Archives-Hash: dc9b1383615e81b0c98606f82ae41e7f On Thu, Jul 19, 2012 at 9:43 AM, Alan McKinnon wrote: > On Thu, 19 Jul 2012 16:31:42 +0300 > Nikos Chantziaras wrote: > >> On 19/07/12 16:03, Michael Mol wrote: >> > On Thu, Jul 19, 2012 at 8:55 AM, Nikos Chantziaras >> > 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