I think this requires some clarifications, > The memory bug that keeps BeOS from using more than 1 gig It's not a bug. > can now be fixed since we no longer are worried about binary compatibility. > It's pretty easy to make a flat 32 bit memory model that accesses the full 4 > gigs Physical memory limitations in BeOS have nothing to do with memory model but with address space management policies. Address space != Physical Memory Size > *plus* with some additional virtual paging code the model can be extended to > super-pages or 4 gig blocks (or parts of blocks) swapped from the HD. > Depends on how big everyone thinks things will get in 2 years. This full paragraph makes me think that you don't fully understand VM management. > Just make sure to use 64 bit counters in all your structs so that when BeOS > requires porting to wider architecture the underlying framework can support > the move. That's the wrong policy... you must make sure that all your scalar types are properly typedef'ed instead of using shorts, ints, longs all over the place. Forcing them to be 64 bits imposes unrequired overhead. Properly typedefing allows you to move to another architecture without putting unrequired overhead. manuel, [ back to lurk mode ] > (ie: 64 bit MPU) > > Peter >