Implement SetConsolePalette (see r59711 for more details), but it is still WIP:
- the helper function ConDrvSetConsolePalette uses a hardcoded palette for testing purposes,
- lots of DPRINT1 are displayed when using this function or when swapping active screen buffers,
- lot of code redundancy which will be put in some helper functions when this code will work correctly,
- and I get some WIN32K warnings:
WARNING: IntGdiRealizePalette at ../../win32ss/gdi/ntgdi/palette.c:777 is UNIMPLEMENTED!
It would be great if a win32k guy can have a look at this!! And I suspect that's because of this that the changed palette is not used...
Also, deactivate the WM_NCRBUTTONDOWN/WM_NCRBUTTONUP hack I introduced in revision 58632, because James worked on this in revisions 60622 and 60626 (see CORE-7054 too).
svn path=/trunk/; revision=60629
* Make npfs_new the one and only npfs. One of the few foo_new modules that actually made it and I hope it won't be the last ;)
CORE-7451
svn path=/trunk/; revision=60611
- Macros renaming.
- When switching active screen buffers, do it a bit more properly, i.e. announce it to the terminal emulator (aka. frontend) so that it will be able to change the associated console palette, be able to support displaying multi screen buffers or displaying another screen buffer than the active one (for debugging purposes or whatever), etc...
There are still some hacks and commented code, which whill be cleaned when I'll be sure that everything works and is not broken somewhere.
svn path=/trunk/; revision=60593
- Setup small icon support from create window not in register class.
- Remove flags if not inside the current version control. Version control is still FIXME.
svn path=/trunk/; revision=60592
- 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
