On Mon, 1 Mar 2004 00:53, Jakob Eriksson wrote:
Somebody made a patch to support this in the past, but it was not the proper way to do it. It's got something to do with address space not being setup the same way as on Windows as far as I can recall.
Part of the problem is that there doesn't appear to be a "right" way to do it. I think one of the "hacks" just prevented NtQueryVirtualMemory from indicating there was a block of memory crossing the 0x80000000 boundary.
Under Windows, it's only on the "Enterprise Edition" operating systems that such a result could be returned from NtQueryVirtualMemory, so this is perhaps not as incorrect as might otherwise be thought. On non EE NT systems, the user address space ends at 0x7fffffff. On Windows 95 series systems, there is a bunch of memory already allocated at 0x7fffffff and down, thus preventing there from ever being a single block of memory (allocated or unallocated) crossing this boundary.
On the other hand, there's another problem with NtQueryVirtualMemory - it won't report memory that has been used by native executables and libraries, so that, for example, although the "wine-*" executables (and lots of .so files) take up memory, NtQueryVirtualMemory will not report this (unless this has changed recently). It is not out of the question that an application might use NtQueryVirtualMemory to look for a suitable block to allocate and then explicitly request that block, but find that they've actually hit the location where the WINE code is, so that the request fails.
Now on Linux it would be possible to fix NtQueryVirtualMemory to report all allocations by grovelling at /proc/{pid}/maps, but this may not be possible on other systems, or where it is possible will require some other mechanism.
So there's really two issues:
1. How should we deal with the 0x80000000 boundary anomaly?
2. Should we attempt to deal with the fact that NtQueryVirtualMemory doesn't report memory used by native executables and libraries?