reactos/win32ss/user/winsrv/usersrv/init.c

187 lines
5.3 KiB
C
Raw Normal View History

/*
* 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"
#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,
SrvEndTask,
SrvLogon,
SrvRegisterServicesProcess, // Not present in Win7
SrvActivateDebugger,
SrvGetThreadConsoleDesktop, // Not present in Win7
SrvDeviceEvent,
SrvRegisterLogonProcess, // Not present in Win7
SrvCreateSystemThreads,
SrvRecordShutdownReason,
// SrvCancelShutdown, // Added in Vista
// SrvConsoleHandleOperation, // Added in Win7
// SrvGetSetShutdownBlockReason, // Added in Vista
};
BOOLEAN UserServerApiServerValidTable[UserpMaxApiNumber - USERSRV_FIRST_API_NUMBER] =
{
FALSE, // SrvExitWindowsEx
FALSE, // SrvEndTask
FALSE, // SrvLogon
FALSE, // SrvRegisterServicesProcess
FALSE, // SrvActivateDebugger
TRUE, // SrvGetThreadConsoleDesktop
FALSE, // SrvDeviceEvent
FALSE, // SrvRegisterLogonProcess
FALSE, // SrvCreateSystemThreads
FALSE, // SrvRecordShutdownReason
// 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
PCHAR UserServerApiNameTable[UserpMaxApiNumber - USERSRV_FIRST_API_NUMBER] =
{
"SrvExitWindowsEx",
"SrvEndTask",
"SrvLogon",
"SrvRegisterServicesProcess",
"SrvActivateDebugger",
"SrvGetThreadConsoleDesktop",
"SrvDeviceEvent",
"SrvRegisterLogonProcess",
"SrvCreateSystemThreads",
"SrvRecordShutdownReason",
// "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
/* FUNCTIONS ******************************************************************/
// PUSER_SOUND_SENTRY. Used in basesrv.dll
BOOL WINAPI _UserSoundSentry(VOID)
{
// TODO: Do something.
return TRUE;
}
ULONG
NTAPI
CreateSystemThreads(PVOID pParam)
{
NtUserCallOneParam((DWORD)pParam, ONEPARAM_ROUTINE_CREATESYSTEMTHREADS);
DPRINT1("This thread should not terminate!\n");
return 0;
}
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)
{
PUSER_GET_THREAD_CONSOLE_DESKTOP GetThreadConsoleDesktopRequest = &((PUSER_API_MESSAGE)ApiMessage)->Data.GetThreadConsoleDesktopRequest;
DPRINT1("%s not yet implemented\n", __FUNCTION__);
/* Return nothing for the moment... */
GetThreadConsoleDesktopRequest->ConsoleDesktop = NULL;
/* Always succeeds */
return STATUS_SUCCESS;
}
CSR_API(SrvDeviceEvent)
{
DPRINT1("%s not yet implemented\n", __FUNCTION__);
return STATUS_NOT_IMPLEMENTED;
}
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 */
NtUserInitialize(0, NULL, NULL);
/* 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
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
LoadedServerDll->SizeOfProcessData = 0;
LoadedServerDll->ConnectCallback = NULL;
LoadedServerDll->DisconnectCallback = NULL;
LoadedServerDll->HardErrorCallback = UserServerHardError;
LoadedServerDll->ShutdownProcessCallback = UserClientShutdown;
UserServerDllInstance = LoadedServerDll->ServerHandle;
/*** From win32csr... See r54125 ***/
/* Start the Raw Input Thread and the Desktop Thread */
for (i = 0; i < 2; ++i)
{
Status = RtlCreateUserThread(NtCurrentProcess(),
NULL, TRUE, 0, 0, 0,
CreateSystemThreads,
(PVOID)i, &ServerThread, &ClientId);
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 */