- Added patterns for twinui.pcshell.dll as a backup when symbols are not available
- Made LoadSymbols clear the returned symbol data when the version is mismatched
- Failure of hooking functions should not prevent Explorer from loading at all anymore
Unfortunately, besides updating the code to work with Google's latest
changes, commit 2a1aad2 introduced a bug when using the Microsoft
icon pack that prevented the widget from loading. Thus, this commit:
* Fixes that (there was no need for `getElementById('wob_tci').children[0]`
apparently)
* Besides checking for blobs in `src`, it also checks for image names,
since `wob_tci` (main icon) still contains a URL, not a blob
* Fixes `wob_tci` to update with proper icon when interacting with the
widget, for example when selecting a day with a different forecast than
the current conditions
* Simplifies some logic, seems the widget works fine without it
Hopefully this fixes the widget properly.
This basically undoes commit a8c7fba and properly fixes the issue:
it seems Google moved the images in a separate child `img` tag, under
what I was previously looking for. Furthermore, the src is not a URL
anymore, but directly the image encoded in base64. Fortunately, we
can match the last characters against images obtained from their 48px
and 64px endpoints. More details here:
https://github.com/valinet/ExplorerPatcher/discussions/755#discussioncomment-5353030
It seems Google has introduced a bug, where they do not change the
main image when changing to another day in the widget. Hopefully they
will fix it in the future.
The patch has been adapted to employ the old behavior when setup is
elevated using the same credentials, while using the updated code with
`CreateProcessWithTokenW` when otherwise.
Original description (via email):
"I have two accounts on my Windows machine: A normal one that is a
standard user (not admin) which I use as my main account where I have
ExplorerPatcher installed and configured, and an Admin account which is
a Windows administrator account.
During installation and update the installer restarts itself and
requests admin privileges. For this I have to provide the password to
the Admin account. The installer then runs as that Admin user, stops
the explorer process, installs ExplorerPatcher and then tries to start
the explorer again. But the explorer never starts, which leaves me with
an empty screen and a session without an explorer. I can then start a
Taskmanager via Ctrl + Shift + Esc and manually start the explorer, but
this is annoying and maybe even frightening for a nontechnical user.
The reason why the explorer is not started again is that it is started
as the wrong user. It is started as the Admin user, which isn't logged
in so the explorer quits immediately.
The fix is to remember the user that the explorer was running under and
then start the new explorer for that user. I have tested these changes
in a Windows 11 virtual machine, by installing and uninstalling for a
standard user, as well as installing and uninstalling for an
administrator user."
Original patch: https://github.com/Abestanis/ExplorerPatcher/tree/fix_explorer_restart
Credit @Abestanis
When Windows is updated, it may fundamentally change the layout and
functionality of `explorer`'s internal data structure. Since
ExplorerPatcher intensively patches those in order to deliver its
functionality, it may lead to `explorer` crashing when it performs
these modifications while being unaware (outdated) of the latest OS
changes. The worst scenario is when the crashes happen when `explorer`
starts up (for example, when the user logs in), and could cause the
user to experience an endless loop of `explorer` crashes, and leave
him/her unable to practically use the computer.
In order to mitigate this scenario, when `explorer` starts up as the
shell, ExplorerPatcher increments a counter stored in the registry.
After a predefined timeout (by default, 10 seconds), ExplorerPatcher
will reset the counter to 0. If `explorer` crashes during this period,
the counter will not be reset. When `explorer` restarts, the cycle
repeats. If the counter reaches a predefined value (by default, 3),
instead of starting up again normally (and very probably crashing
again), ExplorerPatcher will display a message window informing the
user about what is happening, offering a few suggestions on how to
proceed next and disable its entire functionality until the next
File Explorer restart, in order to give the user a chance to perform
maintenance on the machine.
This fixes Task View and Win-Tab, Alt-Tab breaking after pressing
Win-Tab, flyouts alignment, notification center alignment, Windows key
shortcuts on OS builds 22621.1413+.
Thanks @CthRio for the heads up.
It seems Microsoft updated some stuff in `windowsudk.shellcommon.dll`
and has introduced a new interface (`ITaskbarSettings6`), from which
they call the `GetEffectiveSearchMode` method.
This is not relevant for the Windows 10 taskbar, but the code gets
called there anyway as well, so it had to be patched to support this
new interface.
This fix should address the issue and have ExplorerPatcher still work
on newer 22621-based OS builds, like 1344 ("Moment 2" update).
It seems Google changed the widget and explicitly set a background
color, so this patch takes that into account and removes it.
Previously, the widget did not have a background, rather inheriting it
from the `body` element.
It seems that either the web page, either something in Microsoft's
WebView2 implementation changed so that when
`ICoreWebView2::NavigationCompleted` is fired, the elements of interest
on the page are not ready, which causes all this mess, as you can tell.
The solution for now was to delay the execution of my scripts, which
seemed to have gotten rid of the problem for now. I don't particularly
like the solution, I'd of course want something more robust, but I
guess these are the pitfalls when you do not control the entire
ecosystem...
Amrsatrio
Valentin Radu
KabanFriends