- Fix console apps initialization.
- Add some debug output (NOTE TO MYSELF: remove them when all things work).
- Rewrite ConsoleNewProcess.
- Reorganize SrvAllocConsole and create ConsoleConnect based on SrvAllocConsole.
- Create ConsoleDisconnect which undoes what ConsoleConnect and ConsoleNewProcess did.
- Rework a little bit CsrInitConsole.
Now the console app. initialization algorithm is the following:
1- A process is created, its type (GUI or CUI) is determined (kernel32 and basesrv).
2- ConsoleNewProcess is called (consrv) and makes this new process inherit the console handles table from its parent
(NOTE: this is done for all CUI processes, because at this point, we still don't know whether we must inherit
the handles from the parent or not).
3- (back in kernel32) In BasepInitConsole, we determine whether or not we must create a new console window or use
the parent's one or not using one at all. We (as a client) connect to the console server (consrv) (via CsrClientConnectToServer)
which in turn (via CSRSS mechanism) calls ConsoleConnect. For GUI processes we do nothing. For CUI processes, we initialize
a new console based on properties set in BasepInitConsole.
4- When a process dies, ConsoleDisconnect is called and whether it is a GUI or CUI process, we revert the actions done previously.
Part 2/2
TODO: - Debug the CSR waits.
- Work on the console properties property-sheet.
- See what can be done on http://jira.reactos.org/browse/CORE-122
svn path=/branches/ros-csrss/; revision=58098
- Code reorganization.
- In particular, move IsConsoleHandle macro to a place which it can be used by both kernel32 and consrv.
svn path=/branches/ros-csrss/; revision=58063
- Use the DLL instance for getting its win23 resources.
- Use the CONSOLE_PROCESS_DATA structure (see r57686) for accessing console-specific fields of the processes (instead of using them implemented in the CSR_PROCESS structure).
- Win32CsrDuplicateHandleTable --> ConsoleNewProcess since it's the callback function called when a new process is created, and start to move some hacks currently present in BaseSrvCreateProcess.
TODO: suppress the starting-application-related hacks in BaseSrvCreateProcess (in basesrv).
svn path=/branches/ros-csrss/; revision=57689
- Add consrv to compilation. It compiles now \o/
- Convert the used console-csrss structures to the new ones.
[CSR]
- Continue to move some structures, and temporary activate a symbol.
[WIN32CSR]
- Clean a header.
svn path=/branches/ros-csrss/; revision=57602
- Move all the console subsystem from win32csr to a new server dll called consrv.dll (instead of putting it directly to winsrv.dll). It's because I want to rework on this later on.
Many things must be done in order to achieve the moving (renaming functions, etc...). Tables & symbol names come from http://j00ru.vexillium.org/csrss_list/api_list.html as usual,
but here I took the Win 2k3 ones and I added few Win 7 functions which already existed in our codebase. The other table names are guessed based on what originally existed in csrsrv
and so on. Many stubs are also missing.
Cultural remark: consrv.dll originally existed in Beta releases of Windows NT 3.1 (e.g. the October 1991 one), but was soon merged with winsrv.dll and thus, in subsequent versions of
Windows, the console subsystem is also found in winsrv.dll. See http://www.logotypes.se/NT310CSRSS.txt and http://j00ru.vexillium.org/?p=349#comment-1883. One has to wait until
Windows 7 to see it moving again to conhost.exe.
[CSRSRV]
- Add an explanation comment on what the ValidTable member in the CSR_SERVER_DLL structure is for.
svn path=/branches/ros-csrss/; revision=57597
2012-10-22 23:55:51 +00:00
Renamed from win32ss/user/win32csr/handle.c (Browse further)
