> My understanding with OSX is that currently (Leopard > 10.5 and older) > all apps are 32bit, and thus limited to 4G, but the kernel can > address full 64bits.
Under 10.5 and 10.4 it is certainly possible to build "command line" apps that are properly 64-bit x86-64, but the GUI API is limited to 32-bit. So we had a 64-bit "engine" that communicated with the GUI over sockets, and that seemed to be fine. I think the problem that we have (still have) in fltk itself is that although fltk-1.3 is mostly Quartz based now, there are vestigial bits of Quickdraw here and there, so even if SL has a 64-bit Quartz API fltk will not build in 64-bit mode... Or I could be wrong about that... Matt would likely know the facts. > So the kernel can run 32bit apps, assigning each a 32bit > chunk of the whole 64bit arena. So multiple 32bit apps can > be running using their entire 32bit space without overlapping, > but the apps can't address more than that. Oddly, and this seems to be something that is oddly "unknown", there's no real 4GB limit in intel 32-bit cpu's, because PAE works, and actually works very well (despite what the misinformed may post about it on the interwebs!) A little googling will usually turn up links to pages covering this - in particular, it is possible to "tweak" the 32-bit WinXP kernel to access more than 4GB or RAM, for example. The 4GB limit is only what can be addressed in 32-bits, not necessarily the address space that the CPU can access using PAE. This didn't matter to me when the OSX target was PPC, but it does matter now they have switched to x86 variants... Side note: Neither MS nor Apple seem to be taking much advantage of this capability. You'd almost think they wanted to pretend it didn't work, so that they could sell more new, 64-bit hardware and software... > What I don't know is if one were to compile an FLTK app > for 64bits > under OSX, does any of our code need to be made 64bit aware in > order to communicate with the 64bit native APIs? > > We've surely gone through this with linux, sgi, and > windows 64bit, > with OSX being the last to the plate. I think the Quickdraw leftovers are the problem, but I am probably wrong. If so, it's not just the change of address space, but also the change of underlying API (from Quickdraw to Quartz) that makes the OSX changes trickier. > I think Matt and Mike are probably our resident experts on the > OSX native APIs that FLTK uses. I certainly hope so! Cheers, -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
