[thayne]

I'm intrigued why MS decided to have GlobalMemoryStatus return a negative number if there is more than 4GB, rather than returning the maximum value.

[layer8]

When interpreted as an unsigned integer, it actually corresponds to the maximum value of almost 4 GB (0xFFFFFFFF). Note that the fields are declared as SIZE_T, which is unsigned. (Not sure if they always were.) The installer may be incorrectly assigning the value to a signed integer type.

The actual behavior of GlobalMemoryStatus is a bit more complicated, see https://ftp.zx.net.nz/pub/archive/ftp.microsoft.com/MISC/KB/....

[Narishma]

I think it's worse than that. It returns the max value (2GB) when there is more than 2GB but less than 4GB, but a negative value if there is more than 4GB.

[layer8]

This actually depends on the LARGEMEMORYAWARE flag, see https://ftp.zx.net.nz/pub/archive/ftp.microsoft.com/MISC/KB/....

[zamnos]

2^32 is 4294967296, or 4 GiB. Back before Windows ran on 64-bit machines, 4 GiB was as big a number as a standard int could represent. Updating it for 64-bit mode would mean breaking 32-bit programs, so "fixing" it isn't necessarily an upgrade.

[Twirrim]

I think OP was suggesting that instead of overflowing, the API could have instead returned 2^32 / 4 GiB.

[dhosek]

I was thinking the same. I’m guessing that originally the lack of a bounds check was for efficiency’s sake (save a CPU cycle or two) and they chose not to update it assuming people would use the newer API.

[thayne]

> assuming people would use the newer API

that's a pretty bad assumption for an OS that is notorious for its backwards compatibility.