What is interesting is that XP SP1 did have full PAE support. They replaced it with the artificial 4GB limit in SP2. (The difference between SP1 and SP2 was that AMD64 was invented, and it became apparent MS was going to have a whole new generation of software to sell, beside Itanium, which failed on the desktop.)
He is mad that the people who bought Tiger in April 2005 got over four years of security updates. (As you may know, I am calling for FIVE years of security updates from last date of sale. Meaning, Tiger would have gotten security updates until October 2012.)guzhogi said:
http://www.appleinsider.com/print/0...ard_twice_the_ram_half_the_price_64_bits.html
The 32-bit versions of Windows, Linux, and Mac OS X handled their 4GB limit differently. ...
In 32-bit versions of Linux and Mac OS X, the kernel maps out a 32-bit, 4GB virtual memory space for itself and one for each app (or process). ...
In 32-bit Windows, every app only gets a 2GB virtual address space; the 4GB space afforded by 32-bit addresses is split with the kernel.
It's possible (though not very sensible) to do that, but it's not the case. The client OS do have everything PAE in them, the visible physical memory is limited to 4GB separately. The 4GB limit has nothing to do with a lack of PAE or anything like that, it's an explicit and conscious limit put in place by Microsoft through exactly the same mechanism they use to limit Starter editions to 1GB or Server 2008 Standard to the same 4GB as the desktop editions.
Learn to read. I talked about virtual memory, not physical. Each 32b OSX process gets 4GB of virtual memory, and the kernel gets its own 4GB.
No. The OSX kernel has its own entirely separate address space.
You think wrong.
http://developer.apple.com/iPhone/l...AboutMemory.html#//apple_ref/doc/uid/20001880
That's an interesting API. As far as I know, OSX doesn't have any such API (this is supported by the previous link which basically talks about emulating AWE with mmap and mmunmap)
No and no.
I like slow but steady progress and improvements. As a developer, I subscribe to the idea of releasing early and often, and making products gracefully evolve. Time spans of 3, 4 or 5 years lock everything in place freezing progress in many ways.
So do all others since.
Ah, so you're really just a troll?
It isn't that I can't read. I don't agree with your statement, or Aiden's.edmundo said:
That would be pretty unusual, and the cause of OSX slow performance to other OSes.. But I don't think that is the case. The kernel needs SOME address space at all times.
I don't think you can accomplish what AWE does with mmap, because MMAP itself works within the 4GB address space. Whenever you unmap, you are letting go of the memory. Anonymous memory mappings don't seem to have any way to unmap without the OS releasing the memory that backed the mapping. I read that you can simulate it by using actual disk files+mmap (scratch files), but that isn't the same as AWE.
#include <stdio.h>
#include <stdlib.h>
int main()
{
unsigned int c,e;
unsigned long long d;
d=0;
for (c=30; c>0; c--) {
e=1<<c;
while(malloc(e)){
d+=e;
}
printf("Allocated %llu total, just finished %lu chunk size.\n",d,e);
}
printf("Total allocated is %llu\n",d);
return 0;
}Now, there may be issues with malloc that is preventing this from achieving the 'true' maximum. But running this on G5 w/4GB of RAM, the maximum allocation works out to about 3.43 GiB.
No, Leopard is a good example of marketing. Just because SL has no obvious flashy changes, you feel ripped off. Did you actually read the article? A huge amount of under the hood changes make it well, well, worth the absolutely cheap $30 price tag.