Files
reactos/reactos/lib/rtl
Sir Richard 83a2328786 [NTOS]: Blimey this was a hard one. When using the reserved flag to request 1MB in a new process (which is used for starting SMSS and CSRSS), we must request 1MB - 256 bytes (or any number, actually) to offset the fact that with a base address of 0x4, a 1MB region gets us at 0x100FFF, and not 0xFFFF, because Windows computes ending address *before* alignment, and then returns a new region size for you (so if you pass in 1MB, you get 1MB + 4096KB). In Win32csr, when the code is trying to release 1MB, this ended up in our "Case A", because it would still leave a page in the VAD. Fixed rtl to request just shy off a MB. Verified on Windows as well.
[NTOS]: The fix above was due to fixing "EndingAddress" which was being initialized to zero too late (after writing to it!). This caused allocations with a fixed base address that were already on top of another allocation not to be seen as a conflict, then we tried inserting a VAD and received an ASSERT saying we've already found a VAD there. After fixing the sizing code, the bug above creeped up.
Whoever wrote the NtFreeVirtualMemory test is a godsend. It has been nailing bug after bug in the VAD implementation. Thank you.

svn path=/trunk/; revision=55990
2012-03-04 06:42:49 +00:00
..
2012-02-09 11:54:59 +00:00
2010-02-26 22:57:55 +00:00
2011-10-13 15:16:29 +00:00
2010-02-26 22:57:55 +00:00
2010-02-26 22:57:55 +00:00
2011-09-20 17:33:51 +00:00
2011-12-09 16:47:50 +00:00
2010-02-26 22:57:55 +00:00
2012-02-10 17:36:11 +00:00
2011-02-21 13:33:13 +00:00
2012-02-13 14:35:26 +00:00
2011-10-12 21:11:02 +00:00
2011-10-13 21:48:10 +00:00
2010-02-26 22:57:55 +00:00
2010-02-26 22:57:55 +00:00
2010-09-25 21:20:54 +00:00
2012-02-04 13:47:16 +00:00
2011-12-16 20:12:28 +00:00
2011-09-20 17:33:51 +00:00
2011-09-20 17:33:51 +00:00
2010-02-26 22:57:55 +00:00
2011-09-20 17:33:51 +00:00
2011-08-01 03:23:53 +00:00
2011-12-17 08:30:48 +00:00
2011-12-24 22:45:26 +00:00
2012-02-04 18:35:56 +00:00
2011-12-17 08:22:04 +00:00
2011-11-11 11:55:49 +00:00
2011-11-20 19:45:06 +00:00
2010-02-26 22:57:55 +00:00
2011-08-19 21:14:11 +00:00
2010-02-26 22:57:55 +00:00
2011-08-19 18:39:47 +00:00
2012-01-24 21:56:02 +00:00
2012-02-22 12:02:59 +00:00
2011-09-19 11:09:09 +00:00
2010-02-26 22:57:55 +00:00
2010-02-26 22:57:55 +00:00
2012-02-25 15:20:32 +00:00
2010-02-26 22:57:55 +00:00
2011-10-08 13:50:14 +00:00
2012-02-10 17:36:11 +00:00
2010-02-26 22:57:55 +00:00
2011-08-17 14:04:33 +00:00
2011-09-19 19:31:21 +00:00
2012-02-09 11:54:59 +00:00
2010-02-26 22:57:55 +00:00
2011-09-20 17:33:51 +00:00
2012-02-10 17:36:11 +00:00
2011-08-01 03:23:53 +00:00
2011-09-19 19:31:21 +00:00
2012-02-10 17:36:11 +00:00
2011-09-19 19:31:21 +00:00
2012-02-16 14:37:53 +00:00
2011-02-10 11:47:17 +00:00
2010-02-26 22:57:55 +00:00
2011-02-10 11:47:17 +00:00

RTL restrictions:

ExAllocatePool (and friends) must be used exclusively. RtlAllocateHeap (and friends) must NOT be used! ExAllocatePool (and friends) translate to RtlAllocateHeap (and friends) in ntdll\rtl\libsupp.c.

RtlEnterCriticalSection (and friends) must be used exclusively. ExAcquireFastMutex (and friends) must NOT be used! RtlEnterCriticalSection (and friends) translate to ExAcquireFastMutex (and friends) in ntoskrnl\rtl\libsupp.c. This means that RtlEnterCriticalSection (and friends) can NOT be used recursively in RTL. The reason for choosing RtlEnterCriticalSection (and friends) over ExAcquireFastMutex (and friends) is that the FAST_MUTEX struct is smaller than the RTL_CRITICAL_SECTION struct.