- leaner build part 13 of X
- Get rid of shaders and programs support (with assorted extensions), ARB_multitexture and ATI_envmap_bumpmap extensions.
CORE-7499
svn path=/trunk/; revision=60576
* Fix several logically dead code blocks. CIDs 731580, 731581 and 731582.
* Add a compile time assert to perform a preventive check as suggested by Thomas Faber.
CORE-6681
svn path=/trunk/; revision=60573
Add an apitest for psapi GetDeviceDriverFileName.
I'm looking for help to bring it even farther. Ideally, it would be interesting
to be able to GetDeviceDriverFileName on ntoskrnl base address. The whole point is
about getting it dynamically.
The day we can do it properly, I can predict that it will fail on ReactOS, we're not having
correct paths for KDCOM, HAL, and NTOSKRNL modules in the kernel (thank you FreeLdr? - Where are you
starting '\'?)
svn path=/trunk/; revision=60566
* Move the gecko prompt from the mshtml registration to the second stage installer itself. This allows mshtml to register properly regardless of the availability of the gecko package.
svn path=/trunk/; revision=60565
- Add some descriptions.
- Add HKLM\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping needed for win2k3 basesrv (otherwise it fails to initialize) (and ours when the INI File Mappings functionality will be fully implemented). INI File Mappings allows redirections from e.g. system.ini --> Adequate Registry Key, when you use APIs such that WritePrivateProfileString to write settings in those INI files (for 16-bit compat).
svn path=/trunk/; revision=60563
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
- Use Yes/No instead of Ok/Cancel for "Are you sure you want to delete the power scheme?" Patch by Lee Schroeder.
- Remove some unnecessary casts
CORE-7503 #resolve
svn path=/trunk/; revision=60557
CSR_WAIT_FUNCTION functions are callbacks and therefore are __stdcall aka. NTAPI. Fix this.
Now, using either our csrsrv or win2k3' csrsrv works without problems; there is no console key-press problems anymore (aka. stack corruption when calling multiple times CsrNotifyWait, which called those CSR_WAIT_FUNCTION functions).
svn path=/trunk/; revision=60553
- 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
[RTL]: Stubplement and export RtlConsoleMultiByteToUnicodeN (and fallback to RtlMultiByteToUnicodeN) needed for WIndows 2k3 winsrv.dll
CORE-7481 #comment LdrFlushAlternateResourceModules and RtlConsoleMultiByteToUnicodeN stubplemented in revision 60532.
svn path=/trunk/; revision=60532
SampQueryUserAll: Rewrite the handling of the WhichFields variable in order to simplify the support of trusted user information.
svn path=/trunk/; revision=60527
