On Fri, 11 Feb 2011, Blue Swirl wrote: > On Fri, Feb 11, 2011 at 2:47 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 02/11/2011 06:05 AM, Rob Landley wrote: > >>> > >>> While this assumption works on QEMU's major hosts, it is not generally > >>> true. > >> > >> It is generally true. There is exactly one operating system that > >> decided to go its own way, and the insane legacy reasons they did so are > >> explained here: > >> > >> http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx > > > > Unix could do that because it had the luxury of having introduced 64-bit > > when they already were using int=long=32. So really nobody was using long > > until 64-bit systems came along. Windows instead has to deal with the > > legacy of 16-bit, when long was the only 32-bit type. > > IIRC also Unix was in that situation once (short = int =16, long = 32 bits). > > > I have always agreed with you, but as much as I like LP64, I recently > > changed my mind on this stance. stdint.h means that there is _no reason_ > > why a program cannot be written portably so that it runs on both I32LP64 and > > IL32LLP64 models. > > Using intptr_t is not different from using long. There's also the > advantage that it is a bit more specific. > > > Someone has to do the work, of course, and it's surprising that two people > > (Filip Navara and now Stefan) were brave enough to try it. :) It has to be > > a well-audited change though, not a quick attempt at making it work. > > I'd still be interested to know if QEMU runs on win64. But even if it > doesn't, changing longs to intptr_t and unsigned longs to uintptr_t is > harmless enough that it should be applied nevertheless. Even if > everybody stopped all win32/64 work after that, nothing would be lost > except maybe some beauty in some beholder's eyes. >
Filips port did run on win64 last time i tried. -- mailto:av1...@comtv.ru
