Win+C should open the calendar flyout

[valinet]

As suggested by @Gaurav-Original-ClassicShellTester, Win+C should open the classic calendar flyout. This is especially useful so we can free the notification panel off this duty, so we can see more notifications at a glance. At the moment, Win+C just crashes Explorer, likely because it tries to launch Cortana which it cannot find anymore since it was removed in Windows 11.

[valinet]

Fixed in 40ea50e19cde8e87328a55499d55bf9b19264f93

[Gaurav-Original-ClassicShellTester]

Wow thanks for implementing Win+C. I just found out (my bad) that they changed Win+C to Chat (Microsoft Teams) from Cortana. But it crashes anyway with the Classic Taskbar enabled so that broken hotkey can be useful again.

Also, what is the correct way to upgrade from one version to another of ExplorerPatcher? If the Windows build hasn't changed and when the Windows build has updated? (since they just release 22449.1000 for the Dev channel). Do I just replace dxgi.dll? Or also settings.ini too? Obviously it will only work when the symbols for the new build are available. But what is the step-by-step process to update ExplorerPatcher versions?

Also I think some sort of progress bar or something is needed to let us know if it's still downloading the symbols. I don't know if Microsoft's symbol server is extremely slow at some point during the day but I have a fast 85 Mbps connection - sometimes the symbols download fast, sometimes they take a really long time - it seems to get stuck sometimes.

[valinet]

Symbols download pretty slowly, it is not a fast CDN, as only a niche of people have any use for them, so it doesn't make economical sense to keep them on something faster, probably, even if we are talking about Microsoft here. Symbols are not really needed. We can have preconfigured settings.ini files for each build in the repository, and then you just download the file from there and the application starts right away. I don't know, 4 days ago this had 40% of the functionality it has now, things happened pretty fast and I didn't have time to think through every aspect, plus, I am looking for feedback as well. The algorithm for parsing the symbols and determining offsets is useful even if we distribute preconfigured settings.ini files, since the offsets can be easily determined with that, instead of loading each file in IDA etc.

If we encourage preconfigured settings.ini, no progress bar is needed, which btw would take considerable time to implement and validate for something that is essentially used every now and then... I don't know, I don't see it doing myself any time soon, as I don't know if this model of having the app download symbols and autoconfiguring itself on the fly is the best choice though. Maybe it would be better to hardcode the offsets in the application and update them manually when a new OS build is released. But that, again, introduces problems when a new build gets released, everyone wants the app but no one is available to parse the new files and extract the needed information...

When you change ExplorerPatcher, the dxgi.dll I mean, there is no need to delete settings.ini. Offsets for hooked functions change when the DLL they reside in changes, not the patcher. So if you deleted settings.ini on every patcher update, just DON'T, please. It doesn't make sense. If the patcher needs more offsets as the new version hooks more functions, it will anyway download them again automatically.

When the Windows build changes, I'd advise to delete dxgi.dll from C:\Windows before updating. You update, manually put it back and see if it still works. If not, you check for a new version here, and if available, use that. If you leave it in place during the update, there is a chance that Explorer will have trouble starting and from there a whole slew of problems. This is of course expected and not much can be done about it. This is an in-memory patcher, not a tic tac toe game. It is by it's nature that it works like this and that it is not the most user friendly app out there. It does power things for people willing to deal with the benefits and headaches of running such a setup. I can't predict how Microsoft changes the code to determine its compiler to produce a different assembly than what the program currently expects based on what I saw in the current builds. No one can do that. So this kind of utility is expected to brake. Especially since it does not patch primitives let's say, like idk, DrawWindowTextEx, things that are rock solid stable, that are part of the ABI, it patches functions from implementations of some classes of some programs that are in full development at the moment and for which Microsoft made no commitment to keep in their current form. So yeah, the code is prone to breaking often. Like, people can't expect this to run buttery smooth. If one wants that, use the stock OS files and wait for upstream to implement the features one demands, eventually one should write a post that no one will read on the Feedback Hub. Or one ought to switch to macOS...

So, a smooth sailing in the long term with this kind of patcher can really only be obtained if you were to install it on something like LTSC and then the system files would pretty much remain in their current implementation for a few good years to come. Otherwise, things are going to break from time to time. idk, we'll see, I will upgrade to the new OS build now.

[Gaurav-Original-ClassicShellTester]

I see. Thanks for that explanation. Yes it breaking is to be expected - I understand. I anyway reserve a spare PC for running Windows 11 Insider builds and apps like this so my working laptop is ready for the future. I just wanted to know process of updating it - so as long as Windows binaries don't change drastically, no need to determine the offsets again hence no need to even delete settings.ini. That's good to know.

[valinet]

Yeah, try to keep settings.ini as long as you can. Windows.UI.Xaml is the biggest symbol file by far out of all of them (around 300MB), if I didn't have to include that, the download would have been much faster... Have you upgraded to .176 yet?

[Gaurav-Original-ClassicShellTester]

I am on the Dev channel so it updated to 22449.1000. I couldn't get to try 22000.168.0.15 of ExplorerPatcher before that. Anyway I removed the DLL from the 3 locations before it updated. Put it back but it seems it gets stuck on downloading symbols. explorer.pdb, StartDocked.pdb, StObject.pdb, twinui.pcshell,pdb, twinui.pdb and windows.ui.fileexplorer.pdb get downloaded but the download of the big Windows.UI.xaml.... never starts. This happened with Windows 11 22000.168 also when I updated from .14 to .15. So I deleted the settings.ini and then it re-downloaded.

After a restart of Explorer or log out/log in, it seems to delete and download some existing symbol files again but the big one Windows.UI.xaml never begins. Minus that big file, the other symbols are 62.9 MB which have all downloaded. I thought it should at least appear in File Explorer if it had started downloading.

[valinet]

To skip that file, you can trick settings.ini with some fake symbols. Windows.UI.Xaml is injected only in search anyway. I don't think it gets stuck, it just takes a while to download... the file appears in Explorer only after it is completely downloaded, that's how the API works. So, anyway, wait for it to get stuck to downloading Windows.UI.Xaml, when it gets there, kill it, put some random offsets in the file and start it and it should be all okay. Something like:

[Windows.UI.Xaml]
CJupiterWindow::StaticCoreWindowSubclassProc=1234

[Gaurav-Original-ClassicShellTester]

Why I think it's stuck is because the Wifi adapter shows no traffic after downloading the initial 62.9 MB files in Network Connections. For some reason it is never able to finish downloading all the symbols. And even after using the pre-built Settings.ini, it tries to download them again but never completes. I tried putting in the random offsets too for that file but somewhere something gets stuck. It started happening only after the 22000.168.0.15 update and the new INI published.

[valinet]

It does not get stuck if you have offsets for everything. Look on the example file in the repo (https://github.com/valinet/ExplorerPatcher/blob/master/configs/amd64/22000.168/settings.ini). Use that, you will see Explorer probably crashes. Then add the info from there to the partial file that you get until it gets stuck on the download. Windows.UI.Xaml is downloaded last, you should have the offsets for the rest by then.

[valinet]

Can you upload the partial settings.ini file that you get here?

[Gaurav-Original-ClassicShellTester]

settings.ini.txt

Renamed it to settings.ini.txt for Github to accept it as a file.

[valinet]

Okay, I don't know what to say, I will install the dev build in a VM and test. Don't think it will work on such a higher build out of the box, but we'll see... at least it works on latest 22000.176.

[valinet]

Yeah, so I looked on your file, you need an [OS] section in there if you do not want to end up downloading symbols over and over again. Also, they match what I got on my VM, so that's fine. Indeed, some things changed in StartDocked.dll, that's where it was getting stuck, I determined that by reading over the output in the console (AllocConsole=1). Probably they renamed some method in Start, as I said, it is code very much in development so it is kind of expected.

The great news though is that the old taskbar is still in there, which is great news! Classic context menu in Explorer works as well, Win+X and Win+C work, no logon delay. Other stuff is pretty hard to test, since there is a bug in general in this build that there is a 1-2 minute wait before Start becomes available. It happens even with the regular Windows 11 taskbar, if you restart Explorer, you have to wait 1-2 minutes before the taskbar shows the icons and Explorer becomes usable, until that, it sits in a limbo "not responding" state.

So yeah, if they keep it like this, at least patching Explorer should be doable in this or a similar build.

Also, I attach my generated settings.ini file so you can test as well. Again, drop the DLL only in C:\Windows, do not try to hook Start or search as it probably won't work.

settings.ini.txt

[valinet]

I made a small change and now it fully works (Explorer + Start + search) in 22449.1000. Also, apparently, after connecting to the Internet on the VM, it did some stuff and Start does not delay the startup anymore. I suspect it desperately wanted some data which it couldn't get since I was offline. Which I did because otherwise, the OS wouldn't install.

Anyway, it works. Here is my settings.ini.txt file as well, for convenience.

[Gaurav-Original-ClassicShellTester]

Now working. Thanks you so much. I also now have an idea of how to update it correctly and what to expect when updating in various scenarios (when just the DLL is updated, when Windows build changes).

Btw I had to add ExplorerReadyDelay=600 with StartIsBack enabled. :) The default value (if it is 0 or IDK what ms) isn't working, sometimes works, sometimes not, mostly causing slow logon and Win key not opening Windows 11 menu after logon, but 600 makes everything work. As soon as I completely removed ExplorerReadyDelay, the slow logon and broken functionality are back. But I must have booted and rebooted at least 25-30 times with ExplorerReadyDelay=600 and that always works.

[valinet]

@Gaurav-Original-ClassicShellTester Okay, that's great. My personal suggestion would be to stick with the 22000-based builds for daily driving, especially since you employ so many tools that "mess around" with the way Windows works, as the kind of changes they might do in the OS, mentioning that future builds in the Dev channel may become rougher around the edges, are prone to breaking those tools quicker than on the more stable soon-to-be-RTM release, which is anything 22000-based.

Personally, I always use "stable" Windows builds (quotes intended); Insider builds are traditionally too buggy in my opinion, it is not the kind of beta program that you see on iOS for example, where installing the iOS beta in the Spring basically gets you iOS vNext without having to wait the whole summer for it. Apple's iOS beta builds are sometimes even more stable than Microsoft's Windows production builds =))) so, yeah, Insider I avoid as much as I can. Plus, Insider builds are time bombed, so you are force to upgrade sooner or later. Fortunately, this is not the case for 22000-based builds, another sign this will probably be the "RTM" of Windows 11.

Previously to this, I used the 19041/2/3-based builds, and they pretty much worked fine. I just wanted the under-the-hood improvements (WSL2 mount support, WSL2 GPU compute support, multi monitor enhancements) that they brought with 22000 more than the Windows 11 interface. And as I said, there are still bugs even in this "stable" "almost-ready" version of Windows 11 that presumably launches next month or so, from what I heard. For example, the Windows Hypervisor platform is broken on Ryzen 5000-based CPUs, in like, you cannot launch any VM in either VMware, either VirtualBox when they use the Hyper-V compatibility layer. That's a big deal breaker, as I am forced to use Hyper-V all the time, which I don't always enjoy, to say the least. Once they fix that as well, only then would I consider 22000 to be a solid Windows release.

[valinet]

The bug that I mentioned yesterday about Start taking 2 minutes to load properly on 22449 was apparently caused by some fucked up configuration on Microsoft's servers: https://www.reddit.com/r/Windows11/comments/pgugqr/start_menutaskbar_issues_on_22000176_and_22449/. They eventually realized and pulled that back, presumably when things started working automagically for me in the VM. Yeah, really annoying, another reason to avoid Insider builds, presumably this capability of the OS is dormant in stable versions of the OS.

[Gaurav-Original-ClassicShellTester]

But I do have two other laptops running stable Windows. :) One is in fact on Windows 7/8.1/Windows 10 21H1 triple boot and the other "production" one is on Windows 10 1803 because 1809 and all later releases of Windows 10 introduce a pretty serious bug with multi-monitor, high DPI scenario where the wrong maximized window behind the maximized one you actually clicked to close, gets accidentally activated and closed (causing whatever you were working on to be lost)!

So Insider builds are ok for the 3rd laptop I got specifically for experiments and cutting edge "shock treatment" software. :D All my important data is backed up between the other two machines. On the one where I run the latest Insider dev branch, even if the file system gets corrupted or some 1809 like data loss bug occurs, I am ok. It just replaces a VM's role for me. (I dislike running Windows 10 and 11 in a VM, I don't like the way Hyper-V connects via RDP technologies to the VM - the GPU performance is crap despite RemoteFX, and I don't like the performance of Windows 10/11 in VirtualBox and VMware Workstation either (VMs for earlier versions like 8.1, 7, Vista, XP run fine in these, they literally fly but not Windows 10/11 which feel like they have a lot of managed code deep in the OS).

I do use the Windows Hypervisor Platform too but for running https://github.com/otya128/winevdm with hardware acceleration. I like to run Insider builds on real hardware, since most Microsoft employees apparently test everything in a VM only: https://www.ghacks.net/2019/09/23/former-microsoft-employee-explains-why-bugs-in-windows-updates-increased/. That way I get shocked of any nasty changes or removed features, broken features in advance and can prepare for it. :)

But of course, I won't annoy you to update ExplorerPatcher for every single build if it happens to break it (hopefully it won't but on the off chance that it does). I will report it but I am fine with you supporting only big stable release versions. :)

[valinet]

Okay, interesting. You said you dislike running newer Windows versions in Hyper-V VMs because the graphics performance is pretty low due to the RDP technology the use to show an image from the VM. Also you mentioned RemoteFX. RemoteFX is deprecated, but they fortunately introduced a much better alternative in my opinion: GPU paravirtualization. You enable it for a particular VM, and then your host GPU will be shared with the VM. Then, connect to the VM using Parsec for example, and the graphics performance will be buttery smooth. You can even run games this way and it will look great. The desktop will be hardware accelerated, because the OS in the VM 'sees' your host GPU and uses it to accelerate the desktop. Surprisingly for a Windows feature these days, it pretty much works, you just issue a command and that is all you have to do. It was introduced in 1909 I believe. Here is a video tutorial describing how to use it, I highly recommend watching it if you are interested in trying this out: https://www.youtube.com/watch?v=XLLcc29EZ_8

[Gaurav-Original-ClassicShellTester]

Ooh interesting. I had heard of GPU paravirtualization but wasn't sure if it was supported yet in Hyper-V. MS even mentioned Discrete Device Assignment (DDA) as a replacement for RemoteFX vGPU, yet another unrelated feature but I thought it was a Windows Server exclusive. Frankly, I never bothered to learn how to enable these alternatives since my stable PC is stuck at 1803 (but I think I must upgrade now, I have found a crappy fix/workaround for the wrong maximized window getting closed bug which is to run all HD or even 4K displays at 100% DPI scaling and 1280 x or 1366 x . That eliminates the multi-monitor wrong maximized window closed bug and closes the right window. Otherwise, for System or System (Enhanced) DPI scaled apps, it closes the non-scaled maximized windows behind the one I clicked!

Thanks a lot for that link. I gave up on Hyper-V before 190x for sure, around the time they announced RemoteFX vGPU as deprecated and killed it. But now that you've mentioned GPU-PV, I searched and found some instructions too: https://forum.level1techs.com/t/2-gamers-1-gpu-with-hyper-v-gpu-p-gpu-partitioning-finally-made-possible-with-hyperv/172234 I will try setting it up after seeing that video.

[valinet]

@Gaurav-Original-ClassicShellTester GPU-P is a different thing then DDA though. With GPU-P, multiple VMs share the hosts’ video adapter, while with DDA you simply passthrough an adapter entirely for the exclusive use of a particular VM. And indeed, the problem with DDA is that it is available only on Server SKUs, while GPU-P fortunately is available in client Windows, on Pro editions and up.

What is exactly this bug that you are describing? How to reproduce it?

[Gaurav-Original-ClassicShellTester]

I've emailed you details of the bug since it is not related to this. Btw it looks like some Chinese folks discovered ExplorerPatcher: https://www.pcbeta.com/archiver/tid-1901946.html However they are redistributing the DLL on that site.