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
Avoids spamming
(ntoskrnl\ob\obwait.c:441) Failed to reference the handle with status 0xc0000008
CAutoComplete::FinishCompletion(): Remove two useless 'if (m_pThread || !m_hThread)'
tests: No need to check these after each code instruction...
list() functions expects numerical indices for modification operations
and silently converts everything else to a number (old behaviour).
CMake 3.21 now checks this and throws a warning
Addendum to 608032bd and 835c3023.
The IRQL is actually raised by KeFreezeExecution() and lowered by
KeThawExecution(), always to HIGH_IRQL on MP systems, or if necessary
on UP. These functions are called respectively by KdEnterDebugger()
and KdExitDebugger().
GCC8.4.0 dbg warned about:
[675/1849] Building RC object base/shell/cmd/CMakeFiles/cmd.dir/cmd.rc.obj
In file included from C:/ros/reactos/base/shell/cmd/cmd.rc:87:
C:/ros/reactos/base/shell/cmd/lang/tr-TR.rc:349:61: warning: backslash and newline separated by space
I guess somebody made the checks more strict recently,
because that bug was existing for longer already without
generating any warning for me.
When performing access security check, use the security descriptor that we've captured it to determine based on that descriptor if the client can be granted access or not.
Since VS 16.11 the compiler sometimes emits calls to _RTC_UninitUse, when parts of a bitfield are initialized (See https://developercommunity.visualstudio.com/t/Broken-runtime-checks-with-CL-19293013/1503629). Fix this by using an ULONG instead of a bitfield.
Note: The structure uses a 24 bit bitfield plus an UCHAR, which is supposed to form a 32 bit field, but that doesn't work anyway.
Don't force HRESULT status to DSERR_BUFFERLOST by default in primarybuffer_SetFormat function.
Assign to it S_OK instead, as done in current Wine:
a8583acae9:/dlls/dsound/primary.c#l440
That variable is already set to failure in other appropriate place, when this is indeed needed:
https://git.reactos.org/?p=reactos.git;a=blob;h=b04a526929e4e817ff63aa652530e5901a3253a6;f=dll/directx/wine/dsound/primary.c#l511
The assigned failure status caused executing failure handling code even when the fail actually didn't happen.
In particular, DSOUND_ReopenDevice failed on waveOutOpen call when calling this was not needed.
After my changes, it's called only when needed, i. e., only when the actual failure happens
Otherwise, if all goes good, that code is not called, so the data is transfered successfully and the function is working correctly.
It fixes non-working playback in QMMP 0.11.1 (via DirectSound ouput plugin) and AIMP 3.10 and newer versions.
Also it improves the DirectSound test results from MS DxDiag: now all 4 available tests are passing successfully, instead of only 2.
Other dsound issues also might be fixed as well.
CORE-10907 CORE-14783
