Wait, are all these new WSL2 features already available on .51? i never noticed Also, i think there was a way to isolate the taskbar.dll from the explorer process, i remember seeing this the first time it was discovered that MS planned to split explorer.exe and the taskbar
GUI apps and disk mounting work for me under WSL2 at the moment. Haven't tried GPU compute support, but it should work as it was already supported in Windows 10 Insider afaik. A DLL has to run in a process, I think what they did was to isolate the taskbar code in a separate DLL with the intent of having it in a separate process in the future. At the moment, it is still loaded inside explorer.exe, so not much different than having it built into the exe except making this hack actually possible.
using taskbar.dll also adds a delay to logon and sometimes it bugs out and then the taskbar doesnt unhide
uninstall just user experience package should also bring back the old gui no need to uninstall the whole update
If you do as I described, it adds no delay. Please mention the whole circumstances in which you tested this, and you will soon realize they were not the same as the ones I describe.
I don’t recommend doing this as going back is not that easy, plus you actually lose search, and are stuck with the control center button which duplicates the regular icons that do not work. Have you actually bothered to try what you describe, and see whether it fully works…?
Whatever, it works fine for me, anyway, I will come back in a few hours with a new method, I have found a way to make it work without UndockingDisabled and without any Taskbar.dll and search still works and the Start button is available natively as well. I will edit the post once I finish my research.
who here seriously uses the settings app for anything? (i'm not talking about average users) talkin about power users. i don't. i've got alternatives for all the stuff i require. i still remember first using it when 10 came out and having to go through the damn thing on every reinstall or upgrade to disable all the background and privacy nonsense. pissed me off and wasted time, since then i just restore a load of .reg files on reinstall / upgrade to do all that work in one go. barely touch the settings app anymore, slowly replacing all the settings with 3rd party tools and other workarounds. uwp can still die in a fire iyam. i replaced my tray icon on windows 10 20h2 with network activity indicator 1.8 as the settings app crashes when i view network settings. (works before i disable a bunch of non critical services, sched tasks etc) i used carroll to change screen resolution. i created a html app and put that in control panel to do some other settings t-clock for clock flyout will use FlashTray Pro 5 for WinX replacement if i end up using the server explorer.exe on 11.
What’s a “WNF call”? Anyway, if you know the velocity, share it with us and my app naturally becomes obsolete. Or at least enlighten me on how people figure those out, as I don’t know much about where they are stored etc. Old methods like disassembling and patching the code always work if you can figure out what to do, so they are an actual avenue to exploit rather than a velocity setting that you are sure it’s there but no one knows about it actually. Same with Win+X, if you get past velocities and magic numbers and look a bit on the actual executables that ship with the OS, you find this: * Win+X is hosted by twinui.pcshell.dll in 22000, or twinui.dll historically * twinui exposes a COM service with a method called “ShowLauncherTipContextMenu(point)” that explorer calls when someone right clicks the pearl (the name of the Start button in the classic taskbar); since Open Shell is open source, we can see it does the same thing when invoking the Win+X menu when clicking its custom Start orb * that method is located in twinui or twinui.pcshell as well; but, in Windows 11, as opposed to previous Windows versions, the code simply reads “return 0” - they actually removed all the code to show the menu, so of course nothing happens when you right click Start, it all gets there, the link is still happening, but instead of actual code they just left “return 0” * if you inject code there, you can relatively easily show the menu, as it gets properly built if calling the appropriate method (CLauncherTipContextMenu::_EnsureMenu); what’s left to do is a way to figure out how to use the “CLauncherTipContextMenu::_ExecuteCommand” method that used to be invoked when clicking any of the items and that actually opened whatever thing you clicked on - if I or someone else figures that out, the menu will be back, natively, as the infrastructure is still kind of there; of course it would be much easier with source code, but the diassembly still is better than nothing * the actual Win+X shortcut is also handled in twinui in 19043 as far as I know, maybe the “CImmersiveHotkeyNotification::OnMessage” was responsible, idk, haven’t checked yet, it likely was moved to twinui.pcshell in this version as well I would like for someone to work on this in an open manner to speed things up a bit and get to a result, rather than act superior when all I did was share something I developed in my free time with interested users. Of course if I knew of any velocity that solved this, I would have used that, but since I don’t know, I used the best of my knowledge to come up with an actual working solution that is not even that bad imo, but whatever… The right angle corners can probably be restored too, one has to look on dwm.exe as well and figure it out. I mean, if we had the time and incentive, even Aero Glass or acrylic transparency for windows can be relatively easily achieved, as I have previously worked on this and also shared my unfinished, spaghetti code work that actually worked, for better or worse, so reverting the rounded corners should be relatively easily as well, especially if we get down to it and look on how the executable works and what it does… I don’t think there is a velocity for that, but who knows…
Good news: I have an update available (22000.1.0.1) for my ExplorerPatcher app that restores the power user menu (Win+X) menu using native methods from explorer.exe (most of the stuff is, as I said, still there). I have also uploaded a new binary in the Releases section on Github. This, as stated in the README, only works on 22000.1 as that's the version I use and the app has hardcoded offsets for the files in that build, at the moment. Once the known issues get fixed, I will deploy a method for automatically determining the offsets. Please help me fix the remaining issues so we get this to feature parity with Windows 10.
How to restore Windows 11 to working Windows 10 UI: 1. Don't upgrade to Windows 11. 2. ??? 3. Profit.