Fix CLIENTINFO usermode pointer access once again.
Based on a patch by Michael Fritscher from CORE-10017.
Addendum to 7052282507 (r68702).
CORE-18728 CORE-19014
Many thanks for Simone Lombardo for pointing to the code needing attention
and providing a working proof-of-concept solution.
CORE-12377
CORE-18084
CORE-13889
CORE-19011
Fix a "bug" I introduced in commit 61012eb54.
VideoPortGetAccessRanges() expects the caller to specify at least the
total number of ranges the hardware exposes, otherwise it fails with
ERROR_MORE_DATA. (Tested also with the help of Windows' videoprt.sys.)
On real original XBOX there are three:
```
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV2A [XGPU] [10de:02a0] (rev a1)
Subsystem: Unknown [0000:0000]
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 03
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Memory at f0000000 (32-bit, prefetchable) [size=128M]
Memory at 00000000 (32-bit, prefetchable) [size=512K]
```
Thanks to Stanislav and Daniel for tests on the real XBOX.
These are specified for releasing the hardware resources previously
acquired by either a previous call to VideoPortVerifyAccessRanges()
or a call to VideoPortGetAccessRanges().
CORE-17561, CORE-17932, CORE-18221
Do it at each system startup instead: Remove old DirectX initialization code.
It's now outdated and not needed anymore.
Previously, the corresponding hackish intEnableReactXDriver() function
did two things: load dxg.sys and enable DirectDraw.
Now loading DirectX graphics is done during WINSRV initialization, and
enabling DirectDraw is called during each (and also first) display mode
switch, as in Windows. As debug analysis proves, there are no any other
calls in NtGdiDdCreateDirectDrawObject, besides the corresponding DXG
function.
CORE-17932
[ENG] Implement DirectDraw management in switch display mode functions
(e.g. resolution change, color depth, display frequency etc.):
- Switch DirectDraw instances between the two PDEVs (the current one and
the new one allocated by ourselves) by calling dxg!DxDdDynamicModeChange
function.
- Suspend them before and resume after the display mode switch, by calling
dxg!DxDdsuspendDirectDraw and dxg!DxDdResumeDirectDraw appropriately.
We currently don't have these functions implemented, but MS DXG has, so
it allows to properly manage DirectDraw PDEVs using this driver, similarly
to Windows.
My analysis confirms that these functions are always called in XP/2k3 on
display mode switch, even when there is no any DirectX app running at the
moment. Analyzing their prototypes show that my guesses are correct.
- Initialize hDev and dhpdev members for EDD_DIRECTDRAW_GLOBAL for newly
created surfaces, switch them during mode change and re-initialize after
it also. They are commonly used by DirectDraw stack.
In addition, enable DirectDraw for old and new PDEVs, by calling
dxg!DxDdEnableDirectDraw function.
[NTDDRAW] Additionally, fix usage of DirectDraw lock count in the PDEVOBJ
structure.
- Enable cDirectDrawDisableLocks member for storing its value, instead of
DxDd_nCount, which is marked as ROS-specific.
- Use it in win32k!DxEngGet/SetHdevData for getting/setting DirectDraw
count appropriately.
My analysis also shows that in Windows, the PDEVOBJ::cDirectDrawDisableLocks
method calls DxEngGetHdevData with type 8, which corresponds to our DxDd_nCount.
So there are no doubts that this member is used there.
- Rename DxEngGetHdevData_dd_count alias of type 8 to DxEngGetHdevData_dd_locks,
to match more accurately an actual member name. Update the enumeration
and fix all code parts appropriately.
All these changes allow to properly change display mode during executing
DirectDraw applications, when they try to switch in full-screen mode.
At least a bugcheck that happened before my changes, does no longer appear.
There are still some games that don't run correctly, as if there is no
3D acceleration (which actually exists). This requires further investigations.
Contrary to what is (badly) written on MSDN, this parameter is
*mandatory* when the ranges looked for are on a PCI adapter.
Detected when testing with MS Windows' videoprt.sys on XBOX emulator;
thanks to Simone Lombardo for assistance!
And remove the "!NT_SUCCESS(Status)" check which is excessive, the expected
status will always be STATUS_BUFFER_TOO_SMALL anyway. This should fix
some compilation warnings spotted by GCC. Courtesy goes to Hermes for letting
me know of these warnings.
CORE-18221
Load the DirectX graphics kernel driver (dxg.sys) by win32k at WINSRV
initialization time, in NtUserInitialize(). Keep it always loaded in
memory, as on Windows, instead of loading it only by DirectX dlls.
This fixes the problem of acessing this driver: we need only to call
DxDdEnableDirectDraw() and do other stuff when DirectDraw/Direct3D is
required by anything. In other cases, it is called from win32k PDEV
functions when changing display mode (as in Windows). Since it's used
by other things too, it needs to be always loaded.
Otherwise, if it's not loaded, its APIs are not accessible when needed,
and execution fails.
For example, it fixes display mode change problem in VMWare, when a
new mode fails to be applied. Indeed, when it manages DirectDraw stuff,
it calls DXG routines, and therefore fails if dxg.sys isn't loaded
in memory at this moment.
- Implement InitializeGreCSRSS() initialization routine, that initializes
supplemental NTGDI/GRE data once CSRSS and WINSRV are loaded:
* Call DxDdStartupDxGraphics() inside it, which loads dxg.sys.
* Additionally, move fonts and language ID initialization there, from
win32k!DriverEntry. Confirmed by analysis on Windows.
- Call InitializeGreCSRSS() in NtUserInitialize() main initialization routine
(called by WINSRV initialization).
Moved to NTGDI from previously NTUSER place:
Co-authored-by: Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org>
- Delete the win32ksvc-ros.h file, which was not used
- Use a separate file for x64 (based on 2k3 x64 free)
- Delete w32ksvc.db. It's unused since ages.
These must use the corresponding NtUserSetWindowWord/Long function and cannot use NtUserSetWindowLongPtr, otherwise the function can fail, when there is only space for a LONG, but not for a LONG_PTR at the specified offset.
CORE-18978
Fixes NULL pointer access when e.g. class.lpszClassName == NULL and
the class is registered. The RegisterClass(ExA/W/...) should return 0
instead of throwing an invalid access exception.
However, providing an invalid pointer will trigger a crash.
The Chinese user uses Ctrl+Space key combination to switch between the IME keyboard and the non-IME keyboard. To enable Ctrl+Space, the system has to remember the previous keyboard layout. In IntImmActivateLayout function, remember the previous keyboard layout (hklPrev) to switch back for Chinese IMEs. CORE-18950
Currently, LDEVOBJ_bUnloadImage always returns FALSE due to missing functionality in ntoskrnl.
LDEVOBJ_vFreeLDEV contains an assert that driver is correctly unloaded before freeing it.
Prevent this assert by calling LDEVOBJ_vFreeLDEV only if LDEVOBJ_bUnloadImage succeed.
This can be easily triggered if DrvEnableDriver function (called in LDEVOBJ_bEnableDriver) fails.
The changes of this PR are on EDIT controls.
- Delete composition_len and composition_start members.
- Add EDIT_ImmSetCompositionWindow helper function.
- At EDIT_SetCaretPos, set the position of the composition window.
- We don't use internal composition string. Rely on the composition window.
- Improve WM_IME_STARTCOMPOSITION, WM_IME_COMPOSITION and WM_IME_ENDCOMPOSITION message handling.
CORE-11700
- Call ImmSetCompositionFontW in WM_SETFONT handling of EDIT controls if necessary.
- If the specified font is NULL, then use DEFAULT_GUI_FONT.
CORE-11700
Replace framebuf display driver by framebuf_new display driver
Compile framebuf_new as framebuf.dll, and add it to bootcd/livecd
Remove old framebuf from compilation, to not conflict
fix authored by JIRA-user "TANGaming". I do suspect that the possibility of that nullptr deref was introduced on the master branch by 0.4.13-dev-962-g 4193b8d. Doug Lyons signalled his "ok" regarding the fix in chat already. CORE-18899
