It actually should look like '\\.\DISPLAY<n>' (since it comes from user mode),
which the function expects, and not '\\Device\\Video<n>', like done in the
kernel mode. Otherwise, passing wrong name causes a mismatch.
Fix the problem with video device access (failure with status 0xc0000022 when
trying to open it). Hence, it also fixes the following debug log spam:
'err: Could not open device \Device\Video0, 0xc0000022'.
Addendum to 77e891b8. CORE-17719 CORE-17786
GTK applications call GetQueueStatus(QS_ALLINPUT), where QS_ALLINPUT
specifies the QS_RAWINPUT flag as well, when these are compiled for
Windows XP+, and they expect the call to succeed on this platform.
On one side, ReactOS does not currently support this flag at all, but
since it claims to be XP/2003-compatible, applications may implicitly
expect the flag to be supported by GetQueueStatus() and the function
*NOT* failing when this flag is set.
(Later GTK apps don't care and just call GetQueueStatus(QS_ALLINPUT)
that includes QS_RAWINPUT, and therefore would fail as well on e.g.
Windows 2000...)
Otherwise, an observable effect is that some versions of libgdk-win32-2.0.0.dll
enter into an infinite loop when calling GetQueueStatus(QS_ALLINPUT),
since this call always failed on ReactOS.
On the other side, however, we should honour our winetests that handle
the presence of the QS_RAWINPUT flag and behave differently accordingly.
But since we do not support QS_RAWINPUT yet, we should keep their old
behaviour where QS_RAWINPUT is unused.
Thus, in order to accomodate both sides, we don't fail the GetQueueStatus()
call, but just set the ERROR_INVALID_FLAGS last error and continue it.
This fixes CORE-15686, CORE-17551 and probably CORE-11850.
Fixes also all user32:TrackMouseEvent tests.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
This prevents the tracking menu from erroneously closing itself right after it was opened in some cases.
Fixes CORE-17338 which got unhidden by 0.4.15-dev-1126-g 58b0558f94
And fixes CORE-15760 which got unhidden by SVN r74972 == git 19dd22d422
Since both symptoms look very similar but the unhiding revisions did differ,
that could mean we do have some kind of race condition here.
I guess this fix is more like a workaround. I do intend to port it back nevertheless.
As we are a non PNP driver, the call chain will be
DriverEntry -> VidePortInitialize -> VideoPortFindAdapter -> HwFindAdapter.
If legacy resources are available, we will fail VGAFindAdapter,
so DriverEntry will fail, so vgamp.sys driver won't be used.
CORE-17789
- Rewrite ImmGetImeMenuItemsA and ImmGetImeMenuItemsW functions.
- Add Imm32GetImeMenuItemsAW, Imm32IsImcAnsi, Imm32ImeMenuAnsiToWide and Imm32ImeMenuWideToAnsi helper functions.
- Make IME module's ImeGetImeMenuItems function optional.
CORE-11700
Sync/Port: Metafile code from wine.
Patches by Jacek Caban, Daniel Lehman, Zhiyi Zhang. Gabriel Ivancescu, Michael Stefaniuc, Francois Gouget, Nikolay Sivov Dmitry Timoshkov, Andrew EiKum, Piotr Caban and Alexandre Julliard.
This commit is dedicated to George Bisoc!
This is an addendum to
0.4.15-dev-3174-g dda9c3979e CORE-17769 and
0.4.15-dev-3147-g 3bf7e3ac13 CORE-17754 CORE-17755
We have not seen this happening in real-life yet, but some code-fragments within co_IntSetScrollInfo()
e.g. line 628 if (nBar == SB_CTL) do clearly indicate that nBar can be 2 (SB_CTL).
Some lines below we definitely must not access those 4 static arrays out of bounds then via nBar as access index!
Ftr with a bit of grepping I also found some calls like NtUserSetScrollInfo(Wnd, SB_CTL, &Info, FALSE);
e.g: in win32ss/user/user32/controls/scrollbar.c so I am pretty sure nBar == 2 can happen in practice within co_IntSetScrollInfo().
I question whether any of those reads/writes to those static arrays (or the comparisons) would make any sense on index 2,
so we should aim to eliminate them altogether in the future.
Fixes CORE-17769 'Rapps Listview manual resize may erroneously not draw the triangles sometimes'
This could happen for both: themed and unthemed.
CORE-17769 was a regression introduced by 0.4.14-dev-1134-g 00adb1a3f9
We don't really like the added state in form of the static variables,
but the patch works good from a pure testing-perspective.
Many Thanks to the patches author: Doug Lyons
- Do the kernel/server --> user/client-space pointers conversion within
NtUserProcessConnect(), instead of having the callers of this function
doing this job.
This makes the behaviour Windows-compatible.
NOTE: the gHandleEntries pointer is ReactOS-specific!
- Drop the g_ulSharedDelta global, just use instead gSharedInfo.ulSharedDelta.
- Add extra documentation aspects for NtUserProcessConnect() that are
not yet implemented in ReactOS.
- Improve User32InitializeImmEntryTable function and related.
- Complete win32ss/user/user32/include/immtable.h table.
- Delete a hack in user32.DllMain and apply my magical tricks. This will fix some access violations in IMM32.
- Add some stubs into IMM32.
CORE-11700
CORE-17688
When a new driver is installed for the same device (like VBoxVideo), it uses the same hardware enum registry key and thus reuses the same DisplayId and the same display registry key. Therefore we need to update the setting in that key, even when the key already exists.
This seems to work good and not cause any issues, but testing indicated that on Windows some values are only updated, when the driver has changed. If neccessary, this can be achieved by updating and querying the ActiveService value in the device enum key (e.g. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_80EE&DEV_BEEF&SUSYS_00000000&REV_00\3&267a616a&0&10\Control: ActiveService). If that doesn't match the current device name (from DriverExtension->RegistryPath) the values should be copied over.
Enter an SEH2_TRY one time and do all testing within it instead of entering the SEH_TRY multiple times.
The commit is an addendum to 0.4.15-dev-2734-g 514147776a
Thanks to patches author Doug-Lyons
This is 1:1 the final approved content of #3758, but I committed
by hand and closed the PR to avoid squash+rebase.
in CreateDIBPalette() when passing invalid arguments to CreateDIBSection.
This could be triggered by using the broken test-application "GDIProg".
After this patch not only the BSOD is fixed but also the app does
properly start up, like it is the case on 2k3sp2.
Thanks to the patches author Doug Lyons.
DLGWINDOWEXTRA is 30 (both on win32 and win64). This has storage for the following entries: DWLP_MSGRESULT (0), DWLP_DLGPROC (8), DWLP_USER (16)
We used to store the dialog info pointer using SetWindowLongPtr (DWLP_ROS_DIALOGINFO == DWLP_USER+sizeof(ULONG_PTR) == 24), which was fine on win32, but failed on win64, since there wasn't enough space left (24 + 8 = 32 > 30).
Rewrite the way the DLGINFO pointer is stored, by adding an additional field to the WND structure and set it using NtUserxSetDialogPointer (which is what it is for).
Also fix too small cbWndExtra for the button class.
But include registry changes and INF files depending on SARCH variable.
This commit is expected to uncover pc98vid build error on MSVC 2015.
Addendum to 8c475e4. CORE-17529
Fix Clang-Cl
'...\printerdrivers.c(97,98): warning: variable 'cbBuf' is uninitialized when used here [-Wuninitialized]'
Addendum to 62c4b82.
CORE-14306
CORE-17545
win32ss/user/winsrv/consrv/frontends/wcwidth.c:203:30: warning: result of comparison of constant 262141 with expression of type 'wchar_t' (aka 'unsigned short') is always true [-Wtautological-constant-out-of-range-compare]
(ucs >= 0x30000 && ucs <= 0x3fffd)));
~~~ ^ ~~~~~~~
win32ss/user/winsrv/consrv/frontends/wcwidth.c:203:12: warning: result of comparison of constant 196608 with expression of type 'wchar_t' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare]
(ucs >= 0x30000 && ucs <= 0x3fffd)));
~~~ ^ ~~~~~~~
win32ss/user/winsrv/consrv/frontends/wcwidth.c:202:30: warning: result of comparison of constant 196605 with expression of type 'wchar_t' (aka 'unsigned short') is always true [-Wtautological-constant-out-of-range-compare]
(ucs >= 0x20000 && ucs <= 0x2fffd) ||
~~~ ^ ~~~~~~~
win32ss/user/winsrv/consrv/frontends/wcwidth.c:202:12: warning: result of comparison of constant 131072 with expression of type 'wchar_t' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare]
(ucs >= 0x20000 && ucs <= 0x2fffd) ||
~~~ ^ ~~~~~~~
CORE-17545
Fix 3 warnings:
win32ss/user/winsrv/consrv/alias.c:648:16: warning: variable 'Status' is used uninitialized whenever 'while' loop exits because its condition is false [-Wsometimes-uninitialized]
while (CurEntry)
^~~~~~~~
win32ss/user/winsrv/consrv/alias.c:693:12: note: uninitialized use occurs here
return Status;
^~~~~~
win32ss/user/winsrv/consrv/alias.c:715:9: warning: variable 'Status' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (Header)
^~~~~~
win32ss/user/winsrv/consrv/alias.c:727:12: note: uninitialized use occurs here
return Status;
^~~~~~
win32ss/user/winsrv/consrv/alias.c:771:16: warning: variable 'Status' is used uninitialized whenever 'while' loop exits because its condition is false [-Wsometimes-uninitialized]
while (RootHeader)
^~~~~~~~~~
win32ss/user/winsrv/consrv/alias.c:807:12: note: uninitialized use occurs here
return Status;
It allows to properly pass the surface handle (and palette entry pointer) from MS ddraw into win32k.
Otherwise, they are passing into the wrong parameters of actual NtGdi* function, and due to this,
since they're detected as invalid, they become NULL, and that function does not work correctly.
See https://docs.microsoft.com/en-us/windows/win32/devnotes/-dxgkernel-ntgdiddgetdc for the reference
(and confirmed by our headers).
Required by MS DirectDraw stack (ddraw.dll & dxg.sys).
CORE-17561
Thanks goes to I_Kill_Bugs for the patch (and partly to Kyle Katarn for the PR) and Hermes for tweaking the patch code. Had to make a commit myself as the PR author's account is deleted.
Signed-off by: I_Kill_Bugs (original patch author)
Signed-off by: Kyle Katarn <contact@kcsoftwares.com>
Signed-off by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
