I've read Geoff Chappell's article several times, trying to find some weak spot and I don't see any.
After years of telling people, over and over:
32-bit system won't recognize more than 4GB of RAM
I feel confused to say the least.....
Actually, your still right; obviously there would be no gain to explain to most users that they could hack the kernel to enabled support of 4GB+ of RAM.
I've actually been reading some of his articles. He basically documents inconsistencies on Function documentation. Of course, the fact that the functions he says "they did exist before Version X, but were undocumented" and seems to find that simply unacceptable are almost ALL simple little string utility functions. THere are a few pretty interesting functions in there, with curious names.
I've actually wondered about that whole "32-bit operating systems cannot address more then 4GB of RAM" argument, for the same reasons Geoff stated.
The only thing I can see as an issue here is that 32-bit windows will still use only 32-bit handles; but after some consideration, this might not actually be a problem either, only way to exhaust all possible 32-bit handles would be to have- well, all 32-bit handles. there are 2^32 possible handles, but the data they point to surely consumes more then a single byte of RAM. chances are in the case of 32-bit systems that are using huge amounts of RAM using this hack that it's possible (under undue stress to the system's memory) that the system will actually run out of handles to address the RAM with; and yet still have excess RAM to use.
some might introduce the pagefile into this, but really there is no need. regardless of the actual memory capabilities of the system, on a 32-bit architecture, the memory used by a process is divided into user and system sections; per process data for the system in the upper 32-bits (probably things like window classes and window structures that are accessed via the API and the proper handles with those APIs) and process data in the lower 2GB (the actual data stored by the application). this is unmoving; regardless of the memory or configuration of a 32-bit system no process can allocate more then the available space (normally, the 2GB, but this can be changed with boot switches as well as Linker flags on the executable). So really, Virtual Memory is only used to swap this data into and out of RAM, and really is not addressed directly by the process (it can be, but that's a different story altogether).
Personally, while I find it a tad strange that they would leave this type of thing undocumented, it can easily be gleaned. First off, Windows Server 2003 Enterprise Edition 32-bit can address 32GB of RAM. that should kind of act as a clue that it's probably possible on a 32-bit system; the same licensing applies with processors; the number of usable processors can be found in the registry, too. Even though XP home is only supposed to support 1 processor, that value can be changed.
However- we need to define "support" here; "support" and "can use" are not necessarily symptoms, and I doubt phoning MS with an issue or to report a bug in one of their software programs would really be accepted if you used one of these hacked systems; I think the "supported" maximums simply means that is the maximum they will support; they evidently leave out the whole licensing thing, which isn't surprising. If people knew how to easily, for example, make home edition use more RAM and processors, would they buy the professional edition where that was supported? probably not.
