2013-07-13 04:54:49 +00:00
|
|
|
/*
|
|
|
|
* COPYRIGHT: See COPYING in the top level directory
|
|
|
|
* PROJECT: ReactOS User API Server DLL
|
|
|
|
* FILE: win32ss/user/winsrv/usersrv/init.c
|
|
|
|
* PURPOSE: Initialization
|
|
|
|
* PROGRAMMERS: Dmitry Philippov (shedon@mail.ru)
|
|
|
|
* Hermes Belusca-Maito (hermes.belusca@sfr.fr)
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* INCLUDES *******************************************************************/
|
|
|
|
|
|
|
|
#include "usersrv.h"
|
2014-02-05 16:27:14 +00:00
|
|
|
|
2013-07-13 04:54:49 +00:00
|
|
|
#include "api.h"
|
|
|
|
|
|
|
|
#define NDEBUG
|
|
|
|
#include <debug.h>
|
|
|
|
|
|
|
|
/* GLOBALS ********************************************************************/
|
|
|
|
|
|
|
|
HINSTANCE UserServerDllInstance = NULL;
|
|
|
|
|
|
|
|
/* Memory */
|
|
|
|
HANDLE UserServerHeap = NULL; // Our own heap.
|
|
|
|
|
|
|
|
// Windows Server 2003 table from http://j00ru.vexillium.org/csrss_list/api_list.html#Windows_2k3
|
|
|
|
PCSR_API_ROUTINE UserServerApiDispatchTable[UserpMaxApiNumber - USERSRV_FIRST_API_NUMBER] =
|
|
|
|
{
|
|
|
|
SrvExitWindowsEx,
|
2013-08-30 11:33:25 +00:00
|
|
|
SrvEndTask,
|
|
|
|
SrvLogon,
|
2013-07-13 04:54:49 +00:00
|
|
|
SrvRegisterServicesProcess, // Not present in Win7
|
2013-08-30 11:33:25 +00:00
|
|
|
SrvActivateDebugger,
|
|
|
|
SrvGetThreadConsoleDesktop, // Not present in Win7
|
|
|
|
SrvDeviceEvent,
|
2013-07-13 04:54:49 +00:00
|
|
|
SrvRegisterLogonProcess, // Not present in Win7
|
2013-08-30 11:33:25 +00:00
|
|
|
SrvCreateSystemThreads,
|
|
|
|
SrvRecordShutdownReason,
|
2013-07-13 04:54:49 +00:00
|
|
|
// SrvCancelShutdown, // Added in Vista
|
|
|
|
// SrvConsoleHandleOperation, // Added in Win7
|
|
|
|
// SrvGetSetShutdownBlockReason, // Added in Vista
|
|
|
|
};
|
|
|
|
|
|
|
|
BOOLEAN UserServerApiServerValidTable[UserpMaxApiNumber - USERSRV_FIRST_API_NUMBER] =
|
|
|
|
{
|
|
|
|
FALSE, // SrvExitWindowsEx
|
2013-08-30 11:33:25 +00:00
|
|
|
FALSE, // SrvEndTask
|
|
|
|
FALSE, // SrvLogon
|
2013-07-13 04:54:49 +00:00
|
|
|
FALSE, // SrvRegisterServicesProcess
|
2013-08-30 11:33:25 +00:00
|
|
|
FALSE, // SrvActivateDebugger
|
|
|
|
TRUE, // SrvGetThreadConsoleDesktop
|
|
|
|
FALSE, // SrvDeviceEvent
|
2013-07-13 04:54:49 +00:00
|
|
|
FALSE, // SrvRegisterLogonProcess
|
2013-08-30 11:33:25 +00:00
|
|
|
FALSE, // SrvCreateSystemThreads
|
|
|
|
FALSE, // SrvRecordShutdownReason
|
2013-07-13 04:54:49 +00:00
|
|
|
// FALSE, // SrvCancelShutdown
|
|
|
|
// FALSE, // SrvConsoleHandleOperation
|
|
|
|
// FALSE, // SrvGetSetShutdownBlockReason
|
|
|
|
};
|
|
|
|
|
[CSR]
During my investigations for making working Win2k3 csrsrv.dll (or other CSR servers) into ROS (to compare our behaviour with our own csrsrv.dll and Win2k3 one), I hit a problem: if I test a checked-build version of csrsrv (or other CSR servers), everything was fine when they were loaded, but if I use a release-build version (i.e. without any debug information), I systematically hit a memory access violation which was traced back to the moment when a CSR server's CsrInitialization entry point was called.
So I did the experiment, where I used our (debug-build) csrsrv with a free-build win2k3 CSR server dll (it was winsrv.dll, and I retested with basesrv.dll after). I hit the access violation. But if I took a debug-build version of winsrv.dll, everything was OK.
I then added in our csrsrv' server.c file the following line (around line 212 of the current file version):
DPRINT1("%s ; ServerDll->ValidTable = 0x%p ; ServerDll->NameTable = 0x%p ; ServerDll->SizeOfProcessData = %d ; ServerDll->ConnectCallback = 0x%p\n", DllString, ServerDll->ValidTable, ServerDll->NameTable, ServerDll->SizeOfProcessData, ServerDll->ConnectCallback);
and I saw that, when using a debug-build win2k3 CSR server, everything was fine (in particular the ServerDll->SizeOfProcessData member contained a reasonable value, e.g. a size of 88 bytes), whereas if I used a free-build version, I got an off-by-one problem, with the ServerDll->ValidTable pointer valid but the ServerDll->NameTable member being equal to 88 (i.e. invalid pointer) and the ServerDll->SizeOfProcessData member being equal to a very large value, which looked like a pointer value.
After more investigations, I saw that in debug-build CSR servers the list of API names were stored, whereas it was not the case in free-build versions. Therefore I concluded that the API names table was included *ONLY* in debug builds and not in release builds.
Hence, to be able to test in ROS either debug-builds or release-builds versions of Windows CSR servers in ROS (and vice-versa), I introduced a #define called CSR_DBG, which is defined only if the DBG macro is != 0, and which is not defined otherwise. When the CSR_DBG flag is defined, API names tables are added in CSR servers and otherwise, they are not.
Therefore, we are now able to test debug-build Windows CSR servers in ROS (the default possibility) or free-build versions of these CSR servers (but first, we have to build the other ones without the CSR_DBG flag, to avoid the off-by-one problem described above).
svn path=/trunk/; revision=60560
2013-10-06 13:33:17 +00:00
|
|
|
/*
|
|
|
|
* On Windows Server 2003, CSR Servers contain
|
|
|
|
* the API Names Table only in Debug Builds.
|
|
|
|
*/
|
|
|
|
#ifdef CSR_DBG
|
2013-07-13 04:54:49 +00:00
|
|
|
PCHAR UserServerApiNameTable[UserpMaxApiNumber - USERSRV_FIRST_API_NUMBER] =
|
|
|
|
{
|
|
|
|
"SrvExitWindowsEx",
|
2013-08-30 11:33:25 +00:00
|
|
|
"SrvEndTask",
|
|
|
|
"SrvLogon",
|
2013-07-13 04:54:49 +00:00
|
|
|
"SrvRegisterServicesProcess",
|
2013-08-30 11:33:25 +00:00
|
|
|
"SrvActivateDebugger",
|
|
|
|
"SrvGetThreadConsoleDesktop",
|
|
|
|
"SrvDeviceEvent",
|
2013-07-13 04:54:49 +00:00
|
|
|
"SrvRegisterLogonProcess",
|
2013-08-30 11:33:25 +00:00
|
|
|
"SrvCreateSystemThreads",
|
|
|
|
"SrvRecordShutdownReason",
|
2013-07-13 04:54:49 +00:00
|
|
|
// "SrvCancelShutdown",
|
|
|
|
// "SrvConsoleHandleOperation",
|
|
|
|
// "SrvGetSetShutdownBlockReason",
|
|
|
|
};
|
[CSR]
During my investigations for making working Win2k3 csrsrv.dll (or other CSR servers) into ROS (to compare our behaviour with our own csrsrv.dll and Win2k3 one), I hit a problem: if I test a checked-build version of csrsrv (or other CSR servers), everything was fine when they were loaded, but if I use a release-build version (i.e. without any debug information), I systematically hit a memory access violation which was traced back to the moment when a CSR server's CsrInitialization entry point was called.
So I did the experiment, where I used our (debug-build) csrsrv with a free-build win2k3 CSR server dll (it was winsrv.dll, and I retested with basesrv.dll after). I hit the access violation. But if I took a debug-build version of winsrv.dll, everything was OK.
I then added in our csrsrv' server.c file the following line (around line 212 of the current file version):
DPRINT1("%s ; ServerDll->ValidTable = 0x%p ; ServerDll->NameTable = 0x%p ; ServerDll->SizeOfProcessData = %d ; ServerDll->ConnectCallback = 0x%p\n", DllString, ServerDll->ValidTable, ServerDll->NameTable, ServerDll->SizeOfProcessData, ServerDll->ConnectCallback);
and I saw that, when using a debug-build win2k3 CSR server, everything was fine (in particular the ServerDll->SizeOfProcessData member contained a reasonable value, e.g. a size of 88 bytes), whereas if I used a free-build version, I got an off-by-one problem, with the ServerDll->ValidTable pointer valid but the ServerDll->NameTable member being equal to 88 (i.e. invalid pointer) and the ServerDll->SizeOfProcessData member being equal to a very large value, which looked like a pointer value.
After more investigations, I saw that in debug-build CSR servers the list of API names were stored, whereas it was not the case in free-build versions. Therefore I concluded that the API names table was included *ONLY* in debug builds and not in release builds.
Hence, to be able to test in ROS either debug-builds or release-builds versions of Windows CSR servers in ROS (and vice-versa), I introduced a #define called CSR_DBG, which is defined only if the DBG macro is != 0, and which is not defined otherwise. When the CSR_DBG flag is defined, API names tables are added in CSR servers and otherwise, they are not.
Therefore, we are now able to test debug-build Windows CSR servers in ROS (the default possibility) or free-build versions of these CSR servers (but first, we have to build the other ones without the CSR_DBG flag, to avoid the off-by-one problem described above).
svn path=/trunk/; revision=60560
2013-10-06 13:33:17 +00:00
|
|
|
#endif
|
2013-07-13 04:54:49 +00:00
|
|
|
|
|
|
|
/* FUNCTIONS ******************************************************************/
|
|
|
|
|
|
|
|
// PUSER_SOUND_SENTRY. Used in basesrv.dll
|
|
|
|
BOOL WINAPI _UserSoundSentry(VOID)
|
|
|
|
{
|
|
|
|
// TODO: Do something.
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2013-08-30 11:33:25 +00:00
|
|
|
ULONG
|
|
|
|
NTAPI
|
2013-07-13 04:54:49 +00:00
|
|
|
CreateSystemThreads(PVOID pParam)
|
|
|
|
{
|
|
|
|
NtUserCallOneParam((DWORD)pParam, ONEPARAM_ROUTINE_CREATESYSTEMTHREADS);
|
|
|
|
DPRINT1("This thread should not terminate!\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-08-30 11:33:25 +00:00
|
|
|
CSR_API(SrvCreateSystemThreads)
|
|
|
|
{
|
|
|
|
DPRINT1("%s not yet implemented\n", __FUNCTION__);
|
|
|
|
return STATUS_NOT_IMPLEMENTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
CSR_API(SrvActivateDebugger)
|
|
|
|
{
|
|
|
|
DPRINT1("%s not yet implemented\n", __FUNCTION__);
|
|
|
|
return STATUS_NOT_IMPLEMENTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
CSR_API(SrvGetThreadConsoleDesktop)
|
|
|
|
{
|
2014-11-28 20:34:16 +00:00
|
|
|
PUSER_GET_THREAD_CONSOLE_DESKTOP GetThreadConsoleDesktopRequest = &((PUSER_API_MESSAGE)ApiMessage)->Data.GetThreadConsoleDesktopRequest;
|
|
|
|
|
2013-08-30 11:33:25 +00:00
|
|
|
DPRINT1("%s not yet implemented\n", __FUNCTION__);
|
2014-11-28 20:34:16 +00:00
|
|
|
|
|
|
|
/* Return nothing for the moment... */
|
|
|
|
GetThreadConsoleDesktopRequest->ConsoleDesktop = NULL;
|
|
|
|
|
|
|
|
/* Always succeeds */
|
|
|
|
return STATUS_SUCCESS;
|
2013-08-30 11:33:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
CSR_API(SrvDeviceEvent)
|
|
|
|
{
|
|
|
|
DPRINT1("%s not yet implemented\n", __FUNCTION__);
|
|
|
|
return STATUS_NOT_IMPLEMENTED;
|
|
|
|
}
|
|
|
|
|
2013-07-13 04:54:49 +00:00
|
|
|
CSR_SERVER_DLL_INIT(UserServerDllInitialization)
|
|
|
|
{
|
|
|
|
/*** From win32csr... ***/
|
|
|
|
HANDLE ServerThread;
|
|
|
|
CLIENT_ID ClientId;
|
|
|
|
NTSTATUS Status;
|
|
|
|
UINT i;
|
|
|
|
/*** END - From win32csr... ***/
|
|
|
|
|
|
|
|
/* Initialize the memory */
|
|
|
|
UserServerHeap = RtlGetProcessHeap();
|
|
|
|
|
|
|
|
/* Initialize the video */
|
2014-11-29 21:19:01 +00:00
|
|
|
NtUserInitialize(0, NULL, NULL);
|
2013-07-13 04:54:49 +00:00
|
|
|
|
|
|
|
/* Setup the DLL Object */
|
|
|
|
LoadedServerDll->ApiBase = USERSRV_FIRST_API_NUMBER;
|
|
|
|
LoadedServerDll->HighestApiSupported = UserpMaxApiNumber;
|
|
|
|
LoadedServerDll->DispatchTable = UserServerApiDispatchTable;
|
|
|
|
LoadedServerDll->ValidTable = UserServerApiServerValidTable;
|
[CSR]
During my investigations for making working Win2k3 csrsrv.dll (or other CSR servers) into ROS (to compare our behaviour with our own csrsrv.dll and Win2k3 one), I hit a problem: if I test a checked-build version of csrsrv (or other CSR servers), everything was fine when they were loaded, but if I use a release-build version (i.e. without any debug information), I systematically hit a memory access violation which was traced back to the moment when a CSR server's CsrInitialization entry point was called.
So I did the experiment, where I used our (debug-build) csrsrv with a free-build win2k3 CSR server dll (it was winsrv.dll, and I retested with basesrv.dll after). I hit the access violation. But if I took a debug-build version of winsrv.dll, everything was OK.
I then added in our csrsrv' server.c file the following line (around line 212 of the current file version):
DPRINT1("%s ; ServerDll->ValidTable = 0x%p ; ServerDll->NameTable = 0x%p ; ServerDll->SizeOfProcessData = %d ; ServerDll->ConnectCallback = 0x%p\n", DllString, ServerDll->ValidTable, ServerDll->NameTable, ServerDll->SizeOfProcessData, ServerDll->ConnectCallback);
and I saw that, when using a debug-build win2k3 CSR server, everything was fine (in particular the ServerDll->SizeOfProcessData member contained a reasonable value, e.g. a size of 88 bytes), whereas if I used a free-build version, I got an off-by-one problem, with the ServerDll->ValidTable pointer valid but the ServerDll->NameTable member being equal to 88 (i.e. invalid pointer) and the ServerDll->SizeOfProcessData member being equal to a very large value, which looked like a pointer value.
After more investigations, I saw that in debug-build CSR servers the list of API names were stored, whereas it was not the case in free-build versions. Therefore I concluded that the API names table was included *ONLY* in debug builds and not in release builds.
Hence, to be able to test in ROS either debug-builds or release-builds versions of Windows CSR servers in ROS (and vice-versa), I introduced a #define called CSR_DBG, which is defined only if the DBG macro is != 0, and which is not defined otherwise. When the CSR_DBG flag is defined, API names tables are added in CSR servers and otherwise, they are not.
Therefore, we are now able to test debug-build Windows CSR servers in ROS (the default possibility) or free-build versions of these CSR servers (but first, we have to build the other ones without the CSR_DBG flag, to avoid the off-by-one problem described above).
svn path=/trunk/; revision=60560
2013-10-06 13:33:17 +00:00
|
|
|
#ifdef CSR_DBG
|
2013-07-13 04:54:49 +00:00
|
|
|
LoadedServerDll->NameTable = UserServerApiNameTable;
|
[CSR]
During my investigations for making working Win2k3 csrsrv.dll (or other CSR servers) into ROS (to compare our behaviour with our own csrsrv.dll and Win2k3 one), I hit a problem: if I test a checked-build version of csrsrv (or other CSR servers), everything was fine when they were loaded, but if I use a release-build version (i.e. without any debug information), I systematically hit a memory access violation which was traced back to the moment when a CSR server's CsrInitialization entry point was called.
So I did the experiment, where I used our (debug-build) csrsrv with a free-build win2k3 CSR server dll (it was winsrv.dll, and I retested with basesrv.dll after). I hit the access violation. But if I took a debug-build version of winsrv.dll, everything was OK.
I then added in our csrsrv' server.c file the following line (around line 212 of the current file version):
DPRINT1("%s ; ServerDll->ValidTable = 0x%p ; ServerDll->NameTable = 0x%p ; ServerDll->SizeOfProcessData = %d ; ServerDll->ConnectCallback = 0x%p\n", DllString, ServerDll->ValidTable, ServerDll->NameTable, ServerDll->SizeOfProcessData, ServerDll->ConnectCallback);
and I saw that, when using a debug-build win2k3 CSR server, everything was fine (in particular the ServerDll->SizeOfProcessData member contained a reasonable value, e.g. a size of 88 bytes), whereas if I used a free-build version, I got an off-by-one problem, with the ServerDll->ValidTable pointer valid but the ServerDll->NameTable member being equal to 88 (i.e. invalid pointer) and the ServerDll->SizeOfProcessData member being equal to a very large value, which looked like a pointer value.
After more investigations, I saw that in debug-build CSR servers the list of API names were stored, whereas it was not the case in free-build versions. Therefore I concluded that the API names table was included *ONLY* in debug builds and not in release builds.
Hence, to be able to test in ROS either debug-builds or release-builds versions of Windows CSR servers in ROS (and vice-versa), I introduced a #define called CSR_DBG, which is defined only if the DBG macro is != 0, and which is not defined otherwise. When the CSR_DBG flag is defined, API names tables are added in CSR servers and otherwise, they are not.
Therefore, we are now able to test debug-build Windows CSR servers in ROS (the default possibility) or free-build versions of these CSR servers (but first, we have to build the other ones without the CSR_DBG flag, to avoid the off-by-one problem described above).
svn path=/trunk/; revision=60560
2013-10-06 13:33:17 +00:00
|
|
|
#endif
|
2013-07-13 04:54:49 +00:00
|
|
|
LoadedServerDll->SizeOfProcessData = 0;
|
|
|
|
LoadedServerDll->ConnectCallback = NULL;
|
|
|
|
LoadedServerDll->DisconnectCallback = NULL;
|
|
|
|
LoadedServerDll->HardErrorCallback = UserServerHardError;
|
2014-11-29 21:19:01 +00:00
|
|
|
LoadedServerDll->ShutdownProcessCallback = UserClientShutdown;
|
2013-07-13 04:54:49 +00:00
|
|
|
|
|
|
|
UserServerDllInstance = LoadedServerDll->ServerHandle;
|
|
|
|
|
|
|
|
/*** From win32csr... See r54125 ***/
|
|
|
|
/* Start the Raw Input Thread and the Desktop Thread */
|
|
|
|
for (i = 0; i < 2; ++i)
|
|
|
|
{
|
2013-08-30 11:33:25 +00:00
|
|
|
Status = RtlCreateUserThread(NtCurrentProcess(),
|
|
|
|
NULL, TRUE, 0, 0, 0,
|
|
|
|
CreateSystemThreads,
|
|
|
|
(PVOID)i, &ServerThread, &ClientId);
|
2013-07-13 04:54:49 +00:00
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
NtResumeThread(ServerThread, NULL);
|
|
|
|
NtClose(ServerThread);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
DPRINT1("Cannot start Raw Input Thread!\n");
|
|
|
|
}
|
|
|
|
/*** END - From win32csr... ***/
|
|
|
|
|
|
|
|
/* All done */
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* EOF */
|