This returns 1413120 in the virtual machine I've been using for testing.
More info: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-getprocessworkingsetsizeex.
This returns 1413120 in the virtual machine I've been using for testing.
More info: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-getprocessworkingsetsizeex.
This returns 1413120 in the VM I've used for testing.
More info: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-getprocessworkingsetsizeex
199 | @@ -200,8 +200,11 @@ void Win32LockedPageAllocator::FreeLocked(void* addr, size_t len) 200 | 201 | size_t Win32LockedPageAllocator::GetLimit() 202 | { 203 | - // TODO is there a limit on Windows, how to get it? 204 | - return std::numeric_limits<size_t>::max(); 205 | + size_t minSet; 206 | + size_t maxSet; 207 | + DWORD flags; 208 | + GetProcessWorkingSetSizeEx(GetCurrentProcess(), &minSet, &maxSet, &flags);
This needs error handling. I think logging a warning and returning 0 is good enough, but right now this will potentially return an invalid or uninitialized value in the case of an error.
That Win32 function doesn't return an error code https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-getprocessworkingsetsizeex.
Concept ACK
Would be good to get some more review here from windows-minded devs maybe @luke-jr @sipsorcery
I don't think this will compile on x86 Windows.
The PSIZE_T output parameters use SIZE_T which has a different definition for x86 and x64. SIZE_T is equivalent to std::size_t for x64 but not x86. The fix is to use SIZE_T instead but that introduces an additional Windows specific type.