It popped up 2-3 times for me during several
months of ros usage and I could continue without
noticing any side effects.
Giannis who once added it, was ok with commenting it.
His words:
This assertion isn't something fatal,
the worst thing that can happen from continuing on it would be
to make the thread get awake more times than it should.
Allocate heap instead of data segment to be used for callbacks on user side.
Move and correct initial hook call out setup. Use it in more than one hook call.
This fixes issues with strings out of alignment and use of kernel pointers.
See CORE-13907 and CORE-16769. KsStudio still needs retested.
Small wow update.
"Scrolling by pressing the scrollbar arrows does not draw the arrows as pressed"
Fixed by a patch of JIRA-user 'I_kill_bugs'. Thank you very much!
The regression was introduced by 0.4.11-dev-586-g
929a2c6637
(which itself aimed to fix CORE-13986,
but not CORE-13918 as erroneously stated in commit comment)
I intend to port this back into 0.4.13-RC later.
A very nice patch of JIRA user "I_kill_Bugs". Many many Thanks!
It addresses:
- CORE-14755 fixed, flashing scrollbar triangles (we know 131 affected apps just from rapps!)
- CORE-13931 fixed, FamiTracker invisible about-dlg
- CORE-14685 improves a bit, but is not entirely fixed
- CORE-11561 improves a bit, but is not entirely fixed
- The patch avoids unnecessary redraws, speeds up GUI interaction and NSIS install times
Jim Tabor had no complains about it, I just did some white-space-tweaks on EOL and indentation.
FTR A testbot run (not on master but on 0.4.13-RC-48-g818e5bc)
https://reactos.org/testman/compare.php?ids=71645,71666 VBox LGTM
https://reactos.org/testman/compare.php?ids=71646,71667 KVM LGTM
I felt tempted to port back, but decided to play safe and commit to master just.
Fixes symptom "mouse pointer vanishes when closing
applications via x in title-bar"
The bug in WIN32SS was unhidden by SVN r65496 == git
5c1a8109c8
, when we introduced explorer_new. The old explorer
had a workaround built within.
Many thanks to patches author James Tabor.
I intend to backport into 0.4.13RC as well.
CORE-15147
- Rename CLIENTTHREADINFO::tickLastMsgChecked into timeLastRead as
documented in https://reactos.org/wiki/Techwiki:Win32k/CLIENTTHREADINFO .
This is the last time the message queue was read.
- This is the structure member one must compare against the current tick
count timestamp in order to heuristically determine whether a message
queue thread is hung!! Fix MsqIsHung() in accordance, add extra debug
logging in order to help us determining which of our code present
regular GUI hangs, and add as well an extra "TimeOut" parameter so as
not to hardcode a fixed value within that function but instead
allowing its caller to specify possible different values.
- THREADINFO::timeLast is on the contrary the last message time stamp,
and will definitively differ from CLIENTTHREADINFO::timeLastRead .
It should only be used for information purposes!
- Accordingly, in NtUserGetThreadState()::THREADSTATE_UPTIMELASTREAD
and in InitThreadCallback(), only (re-)initialize the timeLastRead
member of the CLIENTTHREADINFO structure of the THREADINFO of interest.
- In co_IntPeekMessage(), update more often the timeLastRead timestamp
whenever the current message queue has been read (but NOT timeLast!!
That one will be updated ONLY WHEN a message is found!).
- In co_IntSendMessageTimeoutSingle() first check whether the window to
which we send the message is being destroyed, before checking for
queue hangs etc. Collapse the logic checks for queue hang and increase
the hang timeout check to 4 times MSQ_HUNG (== 4 * 5 seconds) and
display a debug trace.
This is done by creating the volatile key
\Registry\Machine\System\CurrentControlSet\Control\GraphicsDrivers\BaseVideo .
Also cache during first initialization of VIDEOPRT the state of the boot
options BASEVIDEO and NOVESA, so that they can be readily retrieved later
(for example, in VideoPortIsNoVesa()).
CORE-12149
VIDEOPRT:
=========
Improve interfacing with INBV, so as to detect when an external module
acquired INBV display ownership, and whether ownership is being released
later on. (This does NOT rely on hooking!)
For this purpose we improve the IntVideoPortResetDisplayParameters(Ex)
callback that gets registered with an InbvNotifyDisplayOwnershipLost()
call during initialization, and we add a monitoring thread.
The callback is called whenever an external module calls
InbvAcquireDisplayOwnership(), for example the bugcheck code or the KDBG
debugger in SCREEN mode. When this happens, a flag that tells the
monitoring thread to start monitoring INBV is set (ReactOS-specific),
and the display adapters get reset with HwResetHw() (as done on Windows).
Due to the fact that this INBV callback can be called at *ANY* IRQL, we
cannot use dispatcher synchronization mechanisms such as events to tell
the INBV monitoring thread to start its operations, so we need to rely
instead on a flag to be set. And, since INBV doesn't provide with any
proper callback/notification system either, we need to actively monitor
its state by pooling. To reduce the load on the system the monitoring
thread performs 1-second waits between each check for the flag set by
the INBV callback, and during checking the INBV ownership status.
When the INBV ownership is detected to be released by an external module,
the INBV callback is re-registered (this is *MANDATORY* since the
external module has called InbvNotifyDisplayOwnershipLost() with a
different callback parameter!), and then we callout to Win32k for
re-enabling the display.
This has the virtue of correctly resetting the display once the KDBG
debugger in SCREEN mode is being exited, and fixes CORE-12149 .
The following additional fixes were needed:
VIDEOPRT & WIN32K:
==================
Remove the registration with INBV that was previously done in a ReactOS-
specific hacked IRP_MJ_WRITE call; it is now done correctly during the
video device opening done by EngpRegisterGraphicsDevice() in the VIDEOPRT's
IRP_MJ_CREATE handler, as done on Windows.
WIN32K:
=======
- Stub the VideoPortCallout() support, for VIDEOPRT -> WIN32 callbacks.
This function gets registered with VIDEOPRT through an
IOCTL_VIDEO_INIT_WIN32K_CALLBACKS call in EngpRegisterGraphicsDevice().
- Only partially implement the 'VideoFindAdapterCallout' case, that just
re-enables the primary display by refreshing it (using the new function
UserRefreshDisplay()).
VIDEOPRT:
=========
- PVIDEO_WIN32K_CALLOUT is an NTAPI (stdcall) callback.
- In the IntVideoPortResetDisplayParameters(Ex) callback, reset all the
"resettable" adapters registered in the HwResetAdaptersList list.
We thus get rid of the global ResetDisplayParametersDeviceExtension.
- Make the IntVideoPortResetDisplayParameters(Ex) callback slightly more
robust (using SEH) against potential HwResetListEntry list corruption
or invalid DriverExtension->InitializationData.HwResetHw() that would
otherwise trigger a BSOD, and this would be disastrous since that
callback is precisely called when INBV is acquired, typically when the
BSOD code initializes the display for displaying its information...
Extras:
- Validate the IrpStack->MajorFunction in IntVideoPortDispatchDeviceControl()
and implement IRP_MJ_SHUTDOWN handling. Stub out the other IOCTLs that
are handled by VIDEOPRT only (and not by the miniports).
- VIDEOPRT doesn't require IRP_MJ_INTERNAL_DEVICE_CONTROL (unused).
- Implement IOCTL_VIDEO_PREPARE_FOR_EARECOVERY that just resets the
display to standard VGA 80x25 text mode.
CORE-15655
If the owner window doesn't exist or is invisible or has WS_EX_TOOLWINDOW style, HSHELL_WINDOWCREATED regards the window a non-owned window. You can watch the shell hook information by using CORE-15655 ShellHookChecker.zip.
Upon mouse message generation, The states of Shift key and/or Ctrl key must be used. If Shift key is pressed, it enables MK_SHIFT flag of the mouse message. If Ctrl key is pressed, it enables MK_CONTROL flag of the mouse message. CORE-16279
When Themesvc was disabled, some Window titlebar
frames were drawn too thin until the window
was actively resized in y by the user.
That and similar symptoms started to show up after SVN r68904 ==
6dfa71c487
Many thanks to patches author Doug Lyons.
We leave the ticket unresolved still due to explicit request of
James Tabor, who wants to continue working in that context.
I will merge that back into 0.4.13RCs as well.
The submenu of desktop popup menu was erroneously shown at first right click.
- Fix the hit test position that was modified by window style change.
CORE-16382
This fixes regression CORE-16289 where we could not longer
move the taskbar at a different than default location,
as WindowSnap would interfere.
Many Thanks to the patches author Doug Lyons.
Eventually the heuristic that we use here to identify the
taskbar via used window-styles could be improved later.
Theoretically possible that it bails out on some other windows.
The regression was introduced by 0.4.12-dev-373-g
7e396787ed
There were menu drawing regression after 03adec8141.
This PR will fix it. CORE-16244
- We don't have to draw the frame manually because of WS_EX_DLGMODALFRAME extended style.
- We don't need the margins (MENU_TOP_MARGIN and MENU_BOTTOM_MARGIN) in the client area any more because the client area doesn't contain the frame width.
- Use GetSystemMetrics(SM_CXDLGFRAME) and GetSystemMetrics(SM_CYDLGFRAME) for frame width.
With this change we can remove the workaround from the off-screen
menus dropping below their parent.
Many thanks to Joachim for his help debugging / testing this.
CORE-16297
