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/....

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.

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.

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.