Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Joshua Cranmer Newsgroups: comp.lang.java.programmer Subject: Re: 64-bit gotcha Date: Sun, 04 Dec 2011 18:33:15 -0600 Organization: A noiseless patient Spider Lines: 34 Message-ID: References: <4eda8488$0$287$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 5 Dec 2011 00:33:17 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="WpcHJSul77m+zlbR9GVqkA"; logging-data="5041"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/UGqsBUhCfDBmkYksqhiEHnQV3Kkzq/ko=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: Cancel-Lock: sha1:5QZx6nt8lANZe7uj8BToms2BYzs= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10506 On 12/3/2011 4:01 PM, Peter Duniho wrote: > True, Windows does not support that. But it's technically feasible, and > in fact 32-bit Windows supported 32-bit processes calling 16-bit DLLs > (e.g. http://support.microsoft.com/kb/155763). > > It's a fair question to ask why Microsoft didn't do the same for 32-bit > DLLs executing in 64-bit processes. I believe the short answer is that x86-64 is surprisingly different from x86-32; note that, given some experience with so-called "16-bit" x86 code, it was much closer to the same ISA. My very limited experience with some Win16 code indicates that the primary difference is that 16-bit code relies on segmentation a lot more (CS/DS/ES/SS concerns), but it's still in the same processor mode: if not directly the same, the code would still act identically in the two modes. By contrast, x86-64 moves 32-bit and 64-bit code into different processor modes, and the same byte sequence would do different things. For example, e9 is the opcode for a JMP in 32-bit code but a JMP in 64-bit code--it can't act as both at the same time. It still wouldn't be impossible to make 32-from-64 to work, but it would certainly require IPC between a 64-bit real process and a 32-bit shadow process; given undecidability of pointer aliasing (plus loads of pointer punning), it would probably require nontrivial tailoring the 32-bit process to get this to work--which raises the question of why not translate it to 64-bit code in the first place. Now, it is possible to engineer a 64-bit codebase to spin off the 32-bit process itself and manage all of this itself. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth