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
- Fix the second parameter WaitType (aka. NotifyAll) of CsrNotifyWait. Indeed, we used before the constants WaitAll == 0 / WaitAny == 1 (see the WAIT_TYPE enum); however, it appeared that Win2k3's CsrNotifyWait wanted a WaitType parameter == 1 when waiting for all the waits in a given wait-list. Therefore we would have to use WaitAll for waiting for any of the wait blocks, and WaitAny for waiting for all the wait blocks... looks illogical. Therefore I use instead a BOOLEAN variable (that I call NotifyAll) which is TRUE when I want to wait for all the wait blocks, and FALSE otherwise (as done e.g. for the WaitForMultipleObjects API).
- Fix its usage in CONSRV.
Magically fix key presses problems in console, when using Win2k3 csrsrv.dll ...
svn path=/trunk/; revision=60551
- Do not associate the newly created wait block to the waiting thread (in CsrInitializeWait) in case this one is going to terminate, but do it instead in CsrCreateWait, where the check actually takes place.
- Avoid PPORT_MESSAGE casts.
- Fix a list insertion problem in CsrMoveSatisfiedWait.
- Fix some descriptions / comments.
svn path=/trunk/; revision=60541
[CMAKE] Use the same MSVC build flags for x64 as for x86
[SMLIB] Fix MSVC warnings
[MODULES] Don't include optional modules on x64
[NTOSKRNL] Add some missing globals and definitions for x64
[CSRSRV] Fix an MSVC warning
svn path=/trunk/; revision=60325
Stubplement BaseSrvNlsLogon and BaseSrvNlsUpdateRegistryCache needed by Windows-2k3's WINSRV.DLL . Their return value types are unknown, but the number of parameters was obtained by reading http://wcwp.googlecode.com/svn/trunk/wcwp/bin/masm32/include/basesrv.inc .
svn path=/trunk/; revision=60287
[CSRSRV]: CsrInsertThread should call this API to make sure the thread isn't dead already. Update the callers to handle this possible failure.
This behavior was obeserved in Windows' CSRSRV.DLL. It now works in ReactOS as well.
svn path=/trunk/; revision=60059
- Fix header formatting plus windows headers inclusion.
- RtlCreateUnicodeString returns booleans, not ntstatuses, so fix the code appropriately.
svn path=/trunk/; revision=60012
[NTDLL-KERNEL32-BASESRV-WINSRV]: Specify by hand (hackz for MSVC builds) that the dll will be a "Console DLL" (ie. not a native one nor a Gui DLL).
[BASESRV]: Explicitely set the DLL entry point to DllMain (unusued).
[WINSRV]: Explicitely set the DLL entry point to DllMain (unusued) AND REMOVE usage of msvcrt (that might pose problems when testing with Windows msvcrt etc...) and use libcntpr instead.
Thanks to Amine for having helped me in solving a problem with delayed imports.
svn path=/trunk/; revision=59933
- Fix nls.c header information.
- Rename BasepUnknown to BasepDebugProcess according to j00ru's http://j00ru.vexillium.org/csrss_list/api_list.html#Windows_2k3 and what Alex_Ionescu committed in r59879 (deprecated api).
svn path=/trunk/; revision=59884
[BASESRV]: Implement BaseSrvNlsCreateSection, which is needed by Windows kernel32.dll. Also implement the delay-loading functionality it needs.
svn path=/trunk/; revision=59879
[CSRSRV]: Fix definition of CSR_API_CONNECTINFO structure. It is now compatible with Server 2003. Also, set the DebugFlag.
svn path=/trunk/; revision=59864
Use some existing #define'd constants.
[CSRSRV-BASESRV]
- Add CSR version define (based from BASESRV version define).
- Add missing BASESRV structures, taken from https://code.google.com/p/ontl/source/browse/branches/devel/ntl/nt/csr.hxx (OpenNT Native Template Library).
svn path=/trunk/; revision=59779
- Reduce number of hash collisions during bootup from 10 to 0, by choosing 257 (prime number = good) instead of 256 (power of 2 = bad)
- Use ULONG for CsrpStaticThreadCount and CsrpDynamicThreadTotal to fix an MSVC warning.
svn path=/trunk/; revision=59591
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
* This significantly shrinks the dependency tracking data and the compiled objects size, which speeds up the whole build process (especially the incremental builds) accelerating the daily development as a result.
* No intended code changes, ~27% smaller build. Enjoy ;)
svn path=/trunk/; revision=58214
