- PspMapSystemDll and IopDisplayLoadingMessage are called from non-initialization code, so don't put them in .INIT. CmpHiveRootSecurityDescriptor is called from initialization code, but too late in boot, so don't discard it either.
- Trying to enable this for HAL as well leads to a weird crash very early in boot. Investigation is ongoing. Until then we will just have to keep the huge PCI Class/Vendor tables in memory...
- Enable it for Win32k though as it seems to work fine there.
- Remove INIT_FUNCTION from function prototypes, it serves no purpose there.
See issue 10097 for more details.
svn path=/trunk/; revision=68937
- Add InterlockedIn/DecrementUL
- Define NULL to nullptr for C++ code
- Reorder includes a bit. First GDI then USER. Don't include most USER headers for C++ for now.
svn path=/trunk/; revision=66890
Add back support for allocator stack backtraces for GDI objects and dump a list of BTs, when the GDI object table is exhausted. Disabled by default.
svn path=/trunk/; revision=66374
A bit of code reorganization:
- move a maximum of typedefs into their corresponding headers,
- move user heap functionality into a dedicated header,
- add a note in some functions that the first heap mapping entry in the W32 process info structure is dedicated for the global user heap mapping,
- remove extra-parenthesis in casts.
svn path=/trunk/; revision=65863
Reintroduce CSR support for kernel mode, based on code from Ge that was wiped out in revision 58770, and by ntdll CSR code. Is needed for kernel to user-mode CSR callbacks.
For readers, I remind you the big callback picture in the Win32 subsystem:
- In Windows NT 3.1 and 3.51, USER and GDI was modeled against client/server model (USER32.DLL and WINSRV.DLL, and GDI32.DLL and GDISRV.DLL), all running in user mode (using the CSR API).
- Starting Windows NT 4.0 (and up), some USER and GDI parts were moved into kernel mode (in the WIN32K.SYS driver) to speedup communication. We get:
* GDI32.DLL as the client, doing win32k system calls (kernel-mode system calls to win32k),
* and USER32.DLL, WINSRV.DLL and WIN32K.SYS working in tandem, USER32.DLL being the client and {WINSRV.DLL, WIN32K.SYS} being the server.
USER32.DLL can do win32k system calls or CSR calls to WINSRV.DLL (client to server calls). For server-to-server calls, we have WINSRV.DLL
doing win32k system calls, or WIN32K.SYS doing CSR calls back to WINSRV.DLL . Also, there is the possibility for WIN32K.SYS to make user-mode
callbacks to USER32.DLL.
svn path=/trunk/; revision=65817
Merge of the ros-csrss branch created with a three-fold purpose:
- Use the new Windows-compatible Client-Server Runtime Subsystem (csrss + csrsrv)
written by Alex Ionescu to replace the old hacked one. Also the CSR client part,
residing in ntdll, is updated. Some work also done on the dlls side, which
communicate with CSR, namely kernel32.
- Replace our very old win32csr.dll CSR server by the collection basesrv.dll /
winsrv.dll as it is done under Windows.
- Since the console subsystem is (for historical purposes on Windows) the
only subsystem which exploits all the possibilities of the CSR, I decided to
put it in a new CSR dll called 'consrv.dll', even if on Windows it is included
together with other APIs inside the winsrv dll (since Windows NT 3.1 release)
(I took the name 'consrv' from the dll where it was included in Windows NT 3.1
beta from October 1991). Some work was also done on its internal architecture
(the external interface is of course unchanged for compatibility reasons) and a
two-layer approach was developed, using the existing idea of console functions +
GUI or TUI we already had in win32csr:
* the "console server" which dialogs with the console applications,
and which maintains a list of all the created consoles.
* different "front-ends" corresponding to where you want to output
the information (~= console hardware) (Work-In-Progress).
Another idea would be to make those front-ends dynamically-loadable (instead
of being compiled inside consrv).
- I also fixed some parts of the console properties dialog box.
More information can be found in http://www.reactos.org/archives/public/ros-dev/2013-April/016121.html
CORE-122 CORE-2510 CORE-7002 #resolve #comment Committed in revision r58xxx.
svn path=/trunk/; revision=58770
* Put ntoskrnl and ntdll in the same folder, because they both start with nt.
* Place hal next to acpi, they both deal with hardware stuff.
* Move mountmgr next to usb drivers.
* Put the rtl next to the crt, and share as much as possible between the two.
* I'm just kidding, you know, April's fool and all ;)
Here's the real deal:
[WIN32SS]
* And finally, integrate win32k itself into the new file layout. Now the subsystem modules are located close to each other (like gdi32 and ntgdi, or user32 and ntuser).
* Thanks go to the subsystem team for coming up with this nice layout, hopefully this will scale to the whole codebase layout soon.
* Special thanks to Smiley for coming up with this cool idea :)
svn path=/trunk/; revision=56311
