The BalancedRoot.u1.Parent now points to what used to be MemoryAreaRoot. This isn't really the most proper fix out there -- the problem is that React starts with an no root, while Windows
starts with an empty balanced root. So for now we keep doing it the React way, which means we have about 10 ugly typecast hacks. On the other hand, we got rid of more than 100 of them.
svn path=/trunk/; revision=34881
the kernel, it is entirely stupid to do so by completing ignoring the ramifications of this change, and furthermore, to pollute the kernel with typecasts, as well as to introduce non-standard
behavior. Ironically it is ion himself who made this change.
svn path=/trunk/; revision=34879
that actually contained the address space itself (so it wasn't part of any process). Its locks however, were associated to the "current process", which, when this function is called, is the
idle process (which later is cloned into the initial system process). Shortly thereafter, the address space of the "current process" (still, at this point, the idle process) was initialized
with the function reserved for real processes (MmInitializeProcessAddressSpace), which among other things, performed a couple of user-mode mappings (which are irrelevant and should not be
part of the system process address space). This created a weird schism: the kernel address space was actually a global variable associated with no process at all, while the kernel process
had its own address space as well (which was not the kernel address space). It's a miracle this didn't screw anything up especially since whether or not the address space has an owner
determined the lowest address (which means that if the kernel process allocated a memory with its *own* address space, the code would think it was a user-mode process).
This patch gets rid of the kernel address space as a static structure, and instead makes it a pointer into the idle/system process' address space. It also gets rid of MmInitializeKernelAddresSpace
and instead makes use of the existing MmInitializeHandBuiltProcess, cleaning up the user-mode allocations previously made. Even though all address spaces now have an owner and are part of a
process, MmGetAddressSpaceOwner will still return NULL for now, to remain backwards compatible with legacy code.
svn path=/trunk/; revision=34876
the owner process is stored (which we now use to figure out the lowest address). Recall that NULL means kernel, anything else means per-process. This is great, except that after some
painfull header groking, one understands that the PMADDRESS_SPACE structure is actually *not* a separate structure, but embedded within PEPROCESS itself. It is a React-specific structure
(hence the attempts to get rid of it), that seems to have been "overloaded" on top of the VadRoot structure that Windows uses for user-mode memory allocations. To clarify, this structure
is actually embedded inside the process that owns it, except for the kernel address space, which is a global variable. So there's absolutely *no* point in saving a reference to the owner
process, since we'll always be embedded inside it (except for kernel address space).
This patch creates the MmGetAddressSpaceOwner macro which either returns NULL for kernel address space, or uses the CONTAINING_RECORD macro to return the owner (embedded) process.
svn path=/trunk/; revision=34873
lowest address at which the process has allocated memory, but this isn't the case -- the variable actually defines the lowest valid address a process can allocate memory at. This is pretty
much a static value, that was compute by MmInitializeProcessAddressSpace, to either MM_LOWEST_USER_ADDRESS or MmSystemRangeStart, based on whether or not the address space has an owner process
(meaning it is a user-mode address space) or not (meaning it is a kernel mode address space).
This patch removes that value and all the complex code around checking it, and replaces it with a much simpler design: if there is an owner process, use MM_LOWEST_USER_ADDRESS during gap
calculations, otherwise, use MmSystemRangeStart. This is both faster, and wastes less space by not tracking static data.
svn path=/trunk/; revision=34869
- display default volume label "local disk" if there is no title
- verify that provided clsid is valid
- display drive property dialog
- note: changing volume label currently leads to a crash
svn path=/trunk/; revision=34867
then it attempts to solve. The idea is to be able to unmap PDEs when they are not required anymore (a noble idea), which saves you 4KB of non-paged pool whenever a process frees a chunk
of 4MB memory (oversimplification). The problem is that to keep track of this, an extremly expensive series of branches, comparisons, masks and shifts is applied every single time that
a page is mapped or unmapped. It also adds 8KB of non-paged pool to keep track of the references, which in some cases can be more wasteful than keeping the page tables around.
Finally, if the process quickly allocates and de-allocates memory in the same PDE range, we will effectively map and unmap the PDE continously, fragmenting hyperspace and slowing down perf.
This patch removes this functionality from the system and re-uses the code that was already present in Mmi386ReleaseMmInfo (with some optimizations and changes) to do this unmapping when the
process exists. This should make things faster, with a very small amount of increased memory footprint (we're talking about less than 100kb of non paged pool, in worse-case scenarios).
svn path=/trunk/; revision=34865
- CsrFreeProcessData: Merge two ifs with the same condition.
- Use the pointer-to-pointer trick to simplify linked list handling in CsrFreeProcessData, IntInsertAliasHeader, IntInsertAliasEntry, and IntDeleteAliasEntry.
svn path=/trunk/; revision=34858
- Sync the code a lot closer to its x86 counterpart, still more work to be done.
- Very soon, it should be possible to share upward of 50% of the new ARM code with the x86 version of React as well and unify the implementations.
svn path=/trunk/; revision=34857
- Add '#include <cstring>', so newer gcc's don't complain about a missing memset function
See issue #3595 for more details.
svn path=/trunk/; revision=34855
- Even if there is a console, don't do paging when output is redirected to a file; it would just confuse users with prompts they can't see.
- Instead of WriteFile, use WriteConsole (which has a convenient Unicode version).
- Rework the paging algorithm: don't treat end of string the same way as end-of-line (was causing nul bytes to be output after strings that didn't end with \n), and output multiple lines at once when possible.
- Use the screen buffer width, not the window width, to determine when wrapping will happen.
- Take the initial cursor position into account.
svn path=/trunk/; revision=34847
- Also change FilePromptYN and FilePromptYNA to take a resource ID. Remove varargs code which nobody used (and didn't actually work anyway)
svn path=/trunk/; revision=34816
- Move code for handling ^C (plus that weird pseudo-scrolling thing) from ConioProcessChar to ConioProcessKey, so that WriteConsoleInput won't generate ctrl events.
- ConioProcessChar: Remove redundant NULL == Console checks (Console can't be NULL at this point), and move debug message into the check in ConioProcessKey.
svn path=/trunk/; revision=34808
