Since Win+X key doesn't work without downloading symbol files, has anyone managed to preload the symbols so that Win+X will work out of the box without having to have a network connection?
I tried it with the following files and doing a reset, but
twinui.pcshell.pdb keeps getting deleted when explorer restarts.
Code:
StartDocked.pdb 17821696 2022-11-15 19:37
StartUI .pdb 35672064 2022-11-15 19:37
twinui.pcshell.pdb 26677248 2022-11-15 19:37
It would be nice if
i.e. ep_setup_
22621_608_xx_x.exe would include the symbols for that build without requiring a separate download and a network connection.
@valinet Would this be a reasonable request?
At some point in the past, I indeed used to hardcode the symbol information in the executable. It’s a very repetitive task that had to be done very often, that anyone can do but I always had to do it. I got fed up with it, so the compromise was for me to let the code that I since the beginning wrote to grab the data from the symbol file do the same work as I do manually, but having a machine do it. So it does it automatically for users as well. That’s one of the reasons machines were built for, to do things we humans don’t enjoy doing. It works 99% of the times faster and equally well as I’d do it. The 1% is the one time when Microsoft did not publish the symbols in time for a public CU, so I had to open it symbol-less and compare patterns with the previous version and identify the required offsets on a symbol-less disassembly. A joy, indeed.
I don’t know, don’t get me wrong, but having to do that hardcoding sucks every 2 weeks. I see 3 other solutions, but you ask for the one that mentally damages me and I think any individual in the long term the most (hardcoding the symbols). Yeah, rather unreasonable if you ask me, honestly. It may not be what you want to hear, but I say it nevertheless. So, the other 3:
1. Although I sincerely don’t recommend it, as I have repeated multiple times, there’s always this possibility of forking the code and hardcoding the symbol info yourself. There is ready made code already that can be used. You can then grab that binary and deploy it on your networkless machines. Instead, way easier, copy the registry entries containing the symbol data to your other machines. EP downloads the symbol file, extracts info from it and saves it into the registry.
2. Port over functionality relying on symbol data, like Win-X. The proper solution, so to say. StartAllBack reimplemented the Win-X menu for example in their own code. It’s doable, it just takes time and I never got to it considering the code for Win-X is still in twinui.pcshell.dll. This strategy doesn’t work for everything (some symbols unlock neat functionality, like going to All Apps automatically when opening Windows 11 Start and achieving something similar without symbols is much more difficult), but it would work here. Ideally, I’d keep using symbols only for very high valuable features that can’t be achieved by any other means.
3. An alternative to reimplementing Win-X is to have EP download an older version of twinui.pcshell.dll, a known version we hardcode the offsets for, and use that to generate the Win-X menu with. Idk, it’s clunky, but it should equally work, some older Microsoft DLLs are downloaded anyway to provide certain features.
4. Rely on the built-in symbol downloader, parser and extractor from ExplorerPatcher that just needs Microsoft to have published the symbols and for the computer to be connected to the Internet. Of course, this could be extended to allow grabbing from local symbols/network mirror, but it’s too cumbersome and too much work for too big of a niche case, if you ask me
Ofc, I’d prefer to have option 2, to once and for all end this saga, but until I get to that, I get by with 4 just fine. I feel like missing symbols are the reason many times people experience some kind of a hiccup, but this glitchy behavior has been mentioned again and again multiple times, wiki entries are written about it, yet it still causes so much debate and frustration on both sides, unfortunately.
Also, seeing how symbols are somehow painful for a lot of people, I have refrained from basing more functionality on them, even though this severely limits the scope and possibility for patches and make them needlessly more complex or not portable sometimes. Even recently I did not merge a PR for a new feature (eliminate the line under taskbar buttons) because it added further dependency on symbol data.
Too much frustration coming from something born out of a pure desire to learn more and maybe help others during the process as well. Not only this, but after all this time, there are too many frustrating things that accumulated… sorry.
