> Axel Said: >No, NewOS doesn't map all available memory - that's a BeOS only >feature, and is responsible for this hard limit; neither NewOS nor >OpenBeOS have it. >Changing this would almost require a new VM in BeOS, so it's still >there, even in Zeta. Just to add on... There are really two sides of the memory issue - the virtual (address side) and the physical side. On the virtual side, BeOS (as Axel said) maps all of physical memory into an area for the kernel, plus then maps selected areas into user land address space (whatever is available to you). The implementation for OBOS does not do this. There will be a kernel virtual space that is mapped into every process. How big this is is yet to be determined. Let's say, for the sake of arguement, it is 1 gb. This means that you (the user) can have an amount of mapped memory that approaches 3 gb. Probably not quite all of that, but close. On the physical side, there are also limitations due to the x86 architecture. I personally don't see a compelling reason right now to pursue the "heroic" measures for physical memory. That would mean that on x86-32, people would be limited to around 3 gb of physical memory. That isn't really a significant hurdle for anyone right now, I think. ;-) The changes to move to > 3gb or so are a little weird and, honestly, for systems aimed at the desktop, there is no real point in looking at those weird modes. Is that to say that it can't be done? No. I have given it some level of thought. But I think that, for R1, if we can accept ~ 3GB, it will be a wonderful situation. I expect x86-64 to remove those limits and allow us to have more address space and memory than any human being should ever need (famous last words, right?). Should x86-64 be a miserable failure in the marketplace or something (and I don't think that will be the case at all - it looks really compelling to me), we c! an always go back and add. But I am a firm believer in simpler being better.