- 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
