This check doesn't seem to be correct in modern ReactOS. Furthermore, it
actually hadn't been working for a long time until it was uncovered by
the recent system menu changes.
Reverts a hack introduced in 17a315285 (r72517), fixes CORE-19170.
The initial bug described in CORE-2338 is not observed.
Initialize a window's ThreadListEntry as an empty list on creation and only remove the window from the list on destruction, when the entry is not an empty list. Previously the window creation could fail before the list entry was initialized and the window would get destroyed after that, resulting in a NULL pointer dereference.
According to the results of CImage testcase,
the top byte of the GetPixel() return value is
zero if the return is a valid color.
Do bitwise-AND operation if the color value is valid.
CORE-19008
This will make future syncs between those files much easier,
and fixes tons of mixed tab-space-indentation.
Please no whitespace nitpicks when reviewing this commit, it is a SYNC!
The code was passing 0 instead of SECTION_INHERIT::ViewUnmap (2). 0 isn't even a proper constant to be used here. It worked, because MmMapViewOfSection only compares against ViewShare (1) and treats everything else as ViewUnmap.
Use two longs instead of one for the first parameter of EngCreateBitmap export. Make it same as win32k export.
MSDN documentation says that 1st parameter is SIZEL (SIZE) structure, which actually contains 2 longs inside. Sice it is passed by value, it needs to take enough memory when export in dxgthk and redirect to win32k (since it's actually a win32k function).
Fixes the compilation of our dxg.sys when calling dxgthk!EngCreateBitmap from it.
Found during my DirectX investigations.
I just can't stand that whitespace-diff at those 2 if-conditions any longer,
which was introduced into co_WinPosSetWindowPos() by
0.4.13-dev-8-g cfdf36e442
Everytime I port something back, I don't know where to put that diff temporarily.
And I don't want to make the older branches worse as well.
So finally squeeze it out at right-hand-side in master head.
IS_SYSTEM_MENU():
"moved" to ntuser on 6dfa71c (r68904).
IS_SYSTEM_POPUP():
uselessly added on 6fc29cc (r8195).
IS_BITMAP_ITEM():
uses removed on 07b6ddc (r23221).
uselessly copied to ntuser on 6dfa71c (r68904).
CORE-19092
Fixes the behavior of the SPI_SETFONTSMOOTHING system parameter. This also
fixes a bug when trying to select "Use the following method to smooth edges
of screen fonts" in desk.cpl.
Instead of checking if uiParam is equal to two, treat uiParam as a Boolean
that sets font smoothing on or off. This is the correct behavior according
to Microsoft documentation.
Use SpiStoreSzInt method instead of SpiStoreSz to store the value in the registry.
bmBits is only used and assigned on output. It points (holds the address)
to the array of DIB bit values. The "Bits" parameter is however a pointer
to a variable that will receive the address of that array.
So it makes no sense to initially assign bmBits to the value of the Bits
parameter...
I intend to port back the combined work of Thomas Faber and Serge Gautherie in context of CORE 14271.
Both developers fixed wrong retval evaluations for SeSinglePrivilegeCheck() and RtlCreateUnicodeString().
Both functions do return a BOOLEAN, and therefore using NTSTATUS() on them is wrong.
Those bugs have been fixed at multiple places. That is long gone.
But Serge fixed his locations a bit more elegantly, without the need for additional variables.
Therefore this addendum adapts a few of Thomas locations to the improved Serge-ified style.
Yes: I intentionally used a space instead of a minus after the mentioned CORE 14271,
as I don't want that pure stylistic addendum to be linked with the initial ticket anymore.
That would be overkill.
The "dir /w" command didn't look good due to unaligned columns.
- Add sdk/include/reactos/cjkcode.h header file.
- Add ConGetTextWidthA/W helper functions.
- Add base/shell/cmd/wcwidth.c to implement ConGetTextWidthW.
- Use ConGetTextWidth in DirPrintWideList function.
- Adjust some STRING_DIR_HELP5, STRING_DIR_HELP6 and STRING_DIR_HELP8 resource strings to make the column aligned.
CORE-17591
CORE-8394
These caused the "Ignore-next-mouse-event" mechanism of the console
(used e.g. in QuickEdit mode for not triggering the appearance of the
context menu, etc.) to not work.
Please note that these buggy events, that arise when testing ReactOS
in VirtualBox with Mouse Integration is enabled, do not show up when
running instead Windows (2003, ...) in the same configured VM.
Addendum to commits ac51557 (r63792) and 33d8a4b (r67218).
Improved fix for the one reported in PR #5406 by contributor 'whindsaks',
as it keeps the separation between the flag that manages the working-around
of the bug, and the other flag that is used for ignoring the genuine next
mouse event that follows mouse-button-down events.
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.
