reactos

mirror of https://github.com/ApfelTeeSaft/reactos.git synced 2026-09-02 12:23:31 +00:00

T

Alex Ionescu 3c2b7f8a5b [NTOSKRNL]: One of my favorite bugfixes to date: While working on SMSS2, I notice that Win32->NT path conversion is failing and %SystemRoot% is not being translated. Yet, this is supposed to be part of the core environment that the kernel sends to SMSS! I analyze the old SMSS, and in there, it works. Puzzled, I DPRINT1 out the environment only to see that it is empty. I do the same in the kernel -- empty! The old SMSS is currently manually regenerating its critical environment, as if the kernel never sent it (which perfectly hid the bug that our kernel...actually did never send it!). But why were we sending no environment? It turns out our environment string was 0x10000 bytes, just one byte longer than MAX_USHORT and overflowing back to zero -- hence our Appends were all silently failing. But why was our environment string 0x10000, when we allocate 0x1000 bytes only? And here comes the Mm bug. When you allocate virtual memory in Windows you are forced to use 64K alignment, and Windows internally will align the VAD on a 64K boundary. In ReactOS however, we actually allocate, map, and reserve a full 64K memory area, as well as actually modify the region size that the caller has sent, returning the caller a 64K-aligned size no matter what (whereas Windows would return the original 4KB size). I've thus added a simple hack which still allocates a full 64K memory area (who knows what would break if not), but only aligns the region size to a page size -- less swap pages are reserved, and the caller only receives a page-aligned region, instead of 64K. This now fixes ExpLoadInitialProcess and anyone else that was requesting a 4KB page and getting 64KB in exchange...

svn path=/trunk/; revision=55320

2012-01-30 09:42:47 +00:00

reactos

[NTOSKRNL]: One of my favorite bugfixes to date: While working on SMSS2, I notice that Win32->NT path conversion is failing and %SystemRoot% is not being translated. Yet, this is supposed to be part of the core environment that the kernel sends to SMSS! I analyze the old SMSS, and in there, it works. Puzzled, I DPRINT1 out the environment only to see that it is empty. I do the same in the kernel -- empty! The old SMSS is currently manually regenerating its critical environment, as if the kernel never sent it (which perfectly hid the bug that our kernel...actually did never send it!). But why were we sending no environment? It turns out our environment string was 0x10000 bytes, just one byte longer than MAX_USHORT and overflowing back to zero -- hence our Appends were all silently failing. But why was our environment string 0x10000, when we allocate 0x1000 bytes only? And here comes the Mm bug. When you allocate virtual memory in Windows you are forced to use 64K alignment, and Windows internally will align the VAD on a 64K boundary. In ReactOS however, we actually allocate, map, and reserve a full 64K memory area, as well as actually modify the region size that the caller has sent, returning the caller a 64K-aligned size no matter what (whereas Windows would return the original 4KB size). I've thus added a simple hack which still allocates a full 64K memory area (who knows what would break if not), but only aligns the region size to a page size -- less swap pages are reserved, and the caller only receives a page-aligned region, instead of 64K. This now fixes ExpLoadInitialProcess and anyone else that was requesting a 4KB page and getting 64KB in exchange...

2012-01-30 09:42:47 +00:00

rosapps

[SSSTARS]

2011-12-19 10:22:06 +00:00

rostests

[RASAPI32_WINETEST]

2012-01-29 23:00:48 +00:00

wallpaper

Rename the wallpaper to conform with ISO 9660:1988 and make cdmake happy...

2009-02-03 13:26:30 +00:00