Impact: The actual layout setting from Windows Settings -
Personalization - Start is ignored and the "Default" layout setting is
always used when displaying the Windows 11 Start menu on 22621-based
builds when the setting to disable the "Recommended" section is NOT
used in ExplorerPatcher Properties.
Description: The issue has been addressed by remembering the current/
previous setting and using that when setting the height of the pinned
area when the setting to disable the "Recommended" section is NOT
used in ExplorerPatcher Properties, as opposed to the previous behavior
where a hardcoded value was being used.
Impact: Failure to check against a NULL value and dereferencing it
leads to a crash in `explorer.exe` with fault offset 0xfc69 on
22621-based OS builds. This happens when right clicking certain system
tray icons, like "Epic Games Launcher" when using the Windows 11
taskbar.
Description: The issue has been addressed with improved checks: a check
against NULL values is performed before attempting to work with the
data the variables might point to.
The final Windows 11 22H2 that is shipped to users is OS build 22621.
Unfortunately, I updated EP some time ago to 22622. This creates a
discrepancy between the OS build most people have and the version of
EP that they might have installed. Furthermore, I currently test EP
against OS build 22621. To make things more clear, the next version of
EP will have the major build number set to 22621.
In order to have EP use version 22621 from now on and not prevent
updating from EP 22622... to EP 22621..., I devised this workaround
where the EP version is kept to 22622 as far as updates are concerned,
but the internal build number of EP really is set to 22621.
In the future, if we want to bump the EP version to 22622 again, a
regular change in `version.h` will have the setup patcher insert a `!`
as the first character in the hash part of the version string, which
tells the updater to display that version as a real 22622 build and not
artificially decrement it to 22621.
The only slight inconvenience is that, when the next update arrives,
people will be told they upgrade to EP 22622... still, but they will
receive an EP 22621... build. But at least the updater will work and
detect the new version. From there on, subsequent versions will be
shown as 22621 in the notification if the build number for that version
really is 22621.
Adds 2 new tags in the settings file that define the start and end of a
logical section, in order to enable the possibility of hiding parts of
the UI based on the current value of some setting:
;s Taskbar_Windows10Section IsOldTaskbar <- SECTION BEGIN
;g Taskbar_Windows10Section <- SECTION END
For s, the parameters represent these:
* Taskbar_Windows10Section = name of the current section
* IsOldTaskbar = if the check associated with this name (function call)
returns FALSE, the section will not be displayed on the screen; that
is, the code will skip drawing whatever is inside the 2 tags
This commit includes support for the Windows spotlight feature from
22000.708+ OS builds.
Related to this, ExplorerPatcher now offers the following functionality:
* Hide the "Learn about this picture" icon
* Choose which items from the Windows spotlight icon context menu to
have replicated in the desktop context menu (legacy context menu only)
* Set a schedule for "Switch to next picture"
* Manipulate the feature from the Properties UI, bypassing the desktop
icon
sign out process when using the weather widget
The hang was happening because the UI thread of explorer was hanging in
`dllmain!PeopleBand_DrawTextWithGlowHook` in a call to `AcquireSRWLockExclusive`
when the host process for the widget terminated (due to the system shutting
down - the case when hr is 0x800706ba aka "RPC server is unavailable"). When the
remote process dies, say we are in `dllmain!PeopleBand_DrawTextWithGlowHook`;
a call to some interface from it hangs for a bit, and during
that time the calling thread is able to continue its lifetime, during which a
subsequent call to `dllmain!PeopleBand_DrawTextWithGlowHook` is made (another
widget redraw is requested). As SRW locks do not really support recursion (calling
the same function from the same thread), this behavior is then expected and the
whole thing hangs, thus hanging the shutdown process (and explorer's UI thread in
turn). That's why when you clicked "Cancel" when the UI to close hung apps was
displayed at shutdown, you returned to a frozen desktop. Apparently, Windows lets
explorer hang indefinitely at shutdown, which made matters even worse.
The solution is two fold:
* Widget destruction is dispatched to the service thread. This is not strictly
necessary, but allows for better control of where the thing is destroyed from.
* Switched from SRW locks to a critical section, which is a per-thread lock. All
this has to do is make sure the program destroys the widget only when no other
routine (usually drawing stuff) uses it.
This should pretty much mitigate the issue, hopefully.
Valentin Radu