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...
As a way to showcase the `ep_extra` loader I wrote in my
previous commit, I have developed this module which enables the use of
Windows 7's Alt-Tab. Mind you, the implementation might not be
complete and 100% ironed out, but rather a functional preview on what
it can look like.
Grab a copy of `AltTab.dll` from Windows 7 (I have tested against
version 6.1.7600.16385) and place it in `C:\Windows`. Then, reload
`explorer` with the `ep_extra` loader and this module in `C:\Windows`
and when you "alt-tab", you should see the Windows 7 window switcher.
This is not a reproduction - it executes the original code from
Microsoft's DLL, only slightly patched to work properly in with the
updated APIs in the newer Windows versions.
ExplorerPatcher includes a mechanism which allows the user to load
a single DLL, named `ep_extra.dll` and placed in `C:\Windows` when
`explorer.exe` loads. This was long requested by some users who wanted
to perform their own code/initializations/hooks when `explorer` started.
In the mean time, I thought `ep_extra.dll` would work nicely as a
loader for any number of modules. I could've included this functionality
in the main ExplorerPatcher code, but I decided to take it up as a
challenge instead and offer a robust implementation without changing
ExplorerPatcher's main code.
Thus, when using this as `ep_extra.dll`, it will also load DLLs that
match the `ep_extra_*.dll` pattern. These DLLs must export a function
called `setup` which the loader will execute on the thread that is
loading the DLLs. Although not currently checked, return 0 from this
function if your initialization succeeded, or some error code when it
fails.
What's up with the assembly and shell codes and weird threads that I
create? Well, I realized I kind of did a mistake when coding
ExplorerPatcher, in that I should have loaded and executed `ep_extra`
on a seprate thread, not in `explorer`'s main thread. But since I said
I'd do this challenge without changing EP, this was my solution
towards having this `ep_extra` loader do its work, load the other DLLs,
if any, and then unload itself from memory safely and (almost) cleanly
without disturbing the main application right after it does its job.
This way, you can update it seamlessly when `explorer` is running,
which is much more convenient than having to kill `explorer`, replace
the DLL, and then manually reload `explorer`. I don't know if this is
the best way, but it is the way I thought about when realizing that I
cannot call `FreeLibrary` simply, since the "next line" (which would
have been a "return") is well outside of valid memory at that point.
`FreeLibraryAndExitThread` also can't be used since I do not want to
exit `explorer`'s main thread which the loader's function is called on.
Impact: A recent bug report on the Mozilla Firefox issue tracker
(https://bugzilla.mozilla.org/show_bug.cgi?id=1798707) identifies a
crash in the Firefox browser caused by an invalid memory access
performed by ExplorerPatcher (https://crash-stats.mozilla.org/signature/?signature=explorerpatcher.amd64.dll%20|%20%3Cunknown%20in%20Windows.UI.FileExplorer.dll%3E%20|%20explorerpatcher.amd64.dll%20|%20RtlpFindEntry%20|%20RtlpAllocateHeap%20|%20RtlpAllocateHeapInternal%20|%20explorerpatcher.amd64.dll%20|%20RtlDosApplyFileIsolationRedirection_Ustr%20|%20LdrpApplyFileNameRed...&date=%3E%3D2022-11-02T20%3A44%3A00.000Z&date=%3C2022-11-16T20%3A44%3A00.000Z).
This might happen only when the "Register as shell extension: option
is used, and ExplorerPatcher is injected in other processes. Testing
was unable to reproduce the issue, but looking on the crash logs it
was determined that it likely happens in "VnPatchDelayIAT", where
the memory is patched regardless of whether the protection level
actually succeeded changing or not. The call is suspected to fail
when certain antivirus solutions are used, although a clear test case
with this scenario could not be determined.
Also, code review determined that a race condition might happen in both
"VnPatchIAT" and "VnPatchDelayIAT", where some other thread might
unload the module while the code works with it, attempting to patch the
requested function.
Description: The issue has been addressed by improved checks and
ensuring the module is not unloaded while the functions work with it.
The program only attempts to patch the memory if the previous
protection change call actually succeeded. Additionally, the module
reference count is increased prior to working with it when attempting
the patch, in order to prevent other threads from successfully
unloading it. The proposed changes should harden the code against
unexpected behavior and should address the crashes experienced when
the code runs in other processes, including Firefox.
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.
