- Remove ScreenBufferSize member from GUI_CONSOLE_DATA; when building the structure for console.dll, send the actual screen buffer size instead.
- GuiConsolePaint, GuiIntDrawRegion: Adjust coordinates based on buffer's scroll position.
- GuiConsolePaint: Use ConioCoordToPointer when finding attribute at top-left.
- GuiConsoleHandlePaint: Don't leak the DC when the paint rectangle is empty.
- GuiConsoleHandleScroll: Actually update the buffer's scroll position, not just the scrollbar's. Allow scrolling either horizontally or vertically. Fix typo in SB_THUMBTRACK case. Don't rely on GetScrollInfo for bound checking - any thread can sabotage the scrollbar ranges.
- CsrGetScreenBufferInfo: Return the visible area in srWindow.
svn path=/trunk/; revision=34928
- Fixed WH_CALLWNDPROC/RET, now the posted test program works as it should.
- Tested with Opera 9.51, FF, Seamonkey, Abiword, Miranda, Mirc and the rest of our applications.
svn path=/trunk/; revision=34922
- Make MmProbeAndLockPages smart enough to work at DISPATCH_LEVEL
- At Alex' request, remove the stand alone spinlock for the page list, and
use the queued spinlock in the prcb.
svn path=/trunk/; revision=34920
- GuiConsoleHandleNcCreate: Remove window sizing (now done in GuiConsoleInitScrollbar)
- GuiApplyUserSettings: Swap transposed min/max in cursor size calculation; don't assume that the physical top of the buffer is the same as the logical top; fix broken code where HAVE_WMEMSET isn't defined (wrong loop counts, Offset wasn't incremented); fix typo in calculating height difference. If either buffer or window size has changed, call GuiConsoleInitScrollbar.
svn path=/trunk/; revision=34911
but it solves a practical problem, and isn't particularly invasive (the main
change is the call to KdpEnableSafeMem ... everything else could be macroed
out if desired).
This provides armour for kdbg and gdb that avoid faulting on bad addresses by
implementing a simple poor-man's mmu and letting the debuggers use it.
svn path=/trunk/; revision=34904
the new (correct) ASSERT in mutex acquisition in MmProbeAndLockPages, which
was erroneously being called from IoBuildAsynchronousFsdRequest at
DISPATCH_LEVEL.
The only correct course of action when calling IoBuildAsynchronousFsdRequest
at DISPATCH_LEVEL is to MmBuildMdlForNonPagedPool since the buffer must be
nonpaged (if the IRP completes synchronously, we'll still be at DISPATCH_LEVEL)
This is the case when direct io is done at DISPATCH_LEVEL using
IoBuildAsynchronousFsdRequest.
svn path=/trunk/; revision=34899
- For the first time, the entire ARM build of ReactOS builds (for the components we've defined)!
- Now the user-mode fun begins.
svn path=/trunk/; revision=34890
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
