starting at 0x20000000. This should work right from the start in 99%
of the cases. */
uintptr_t start_address = 0x20000000L;
- if ((uintptr_t) NtCurrentTeb () >= 0xbf000000L)
+ MEMORY_BASIC_INFORMATION mbi;
+
+ if (VirtualQuery ((void *) 0xbf000000L, &mbi, sizeof mbi))
{
/* However, if we're running on a /3GB enabled 32 bit system or on
a 64 bit system, and the executable is large address aware, then
we know that we have spare 1 Gig (32 bit) or even 2 Gigs (64 bit)
virtual address space. This memory region is practically unused
- by Windows, only PEB and TEBs are allocated top-down here. We use
- the current TEB address as very simple test that this is a large
- address aware executable.
- The above test for an address beyond 0xbf000000 is supposed to
- make sure that we really have 3GB on a 32 bit system. Windows
- supports smaller large address regions, but then it's not that
- interesting for us to use it for the heap.
- If the region is big enough, the heap gets allocated at its
- start. What we get are 0.999 or 1.999 Gigs of free contiguous
- memory for heap, thread stacks, and shared memory regions. */
+ by Windows, only PEB and TEBs are allocated top-down here.
+
+ We used to use the current TEB address as very simple test that
+ this is a large address aware executable, but that fails on W10
+ WOW64 because the main TEB is apparently commited in the lower
+ 2 Gigs these days.
+
+ The above test for address 0xbf000000 is supposed to make sure
+ that we really have 3GB on a 32 bit system. Windows supports
+ smaller large address regions, but then it's not that interesting
+ for us to use it for the heap. If the region is big enough, the
+ heap gets allocated at its start. What we get are 0.999 or 1.999
+ Gigs of free contiguous memory for heap, thread stacks, and shared
+ memory regions. */
start_address = 0x80000000L;
}
#endif