Delayed Exporer restart during update

[gjf]

Is it possible to ask user: should installer/updater restart Explorer immediately (present action by default) or apply update after reboot?

Sometimes Explorer restart leads to errors especially when active copying process is present - and now it is not possible to prevent it.

[gjf]

What I see: the possibility to choose one of two option: apply immediately (with warning it will restart Explorer) or apply after reboot.
The mechanism is pretty the same: renaming old instance into dxgi.prev (overwriting previous old if present), putting new one dxgi.dll - but after that either explorer restarts or nothing happens.

[valinet]

Nothing happens is not really nothing happens. If you open another Explorer instance, that will load the DLL if you copied it near the exe. So you'll have one Explorer without the DLL, one with... which is not a really thoughtfully tested config, heck, I have never tested that, I kind of always assume I hook all explorers from the get go when they start.

Opening new explorer.exe instances is not that alien either. Set aside the "Launch folders in a separate process" option, which has to be supported as well, the "/factory:" instances (which get spawned when launching Control Panel for example) also are separate instances.

It seems easy on the surface, but believe me, nothing is as simple as it looks, I am speaking from experience, with this software especially.

Doing it properly at reboot would mean setting up a scheduled task for example, instead of restarting Explorer, setting up a scheduled task to run at next boot which would do the actual install and then delete itself. Also, do part of the actual install, because you'd still have to cache the installation program somewhere since the user may delete it from "Downloads", you can't register the task with that path...

Yeah, idk, pretty complicated for something that, I have to admit, looks simple on the surface... It can create confusion for some users and is prone to other weird situations happening and then users blaming the software generally.

[gjf]

OK I didn't think about separate instances. You are correct, putting dll into %windir% is not the best way.
But anyway - isn't it easy to use HKLM\System\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations to perform necessary actions on reboot? What I see: put the current dxgi.dll as dxgi.new into %windir%, add pending actions to rename dxgi.dll > dxgi.prev and dxgi.new > dxgi.dll.
If so - all installation will be performed on reboot and no problem with separate explorer instances.

[valinet]

It's rarely easy. Every new functionality has to be carefully integrated and thoughtfully tested.

Idk... what's the problem again with just rebooting and having it update at next boot? The installer you run it only once... then you update via the app, which I already said happens only when Explorer starts, which is 99% of the time at logon when no user tasks are running anyway...

[gjf]

In fact I did that job using two public tools (movefile and curl) and batch script before you released an installer :)
You can check it: https://github.com/gjf/Windows-11-ExplorerPatcher-Installer/blob/main/Win11EP.bat
Yes it is buggy taking into consideration your comment re second Expolorer instance but it can be updated - but no need as you released an installer already )

As for update on logon - it makes sense but how to do it?
What I see now:

First option will only inform me about update - so I have to install it manually and restart explorer.exe - not my case.
Second option prompts... does it mean it will pause starting other application at logon untill I respond on this prompt?
I don't see the option that automatically install update when Explorer starts at logon.

[gjf]

Idk, I guess I could pop up a window... like, it should be pretty obvious to close other tasks before using this... once you place the DLL in the folder, as soon as you start a new instance, it will get loaded in memory... scheduling it for reboot is too overarching... why not update when you actually reboot, like, this only notifies you about updates when it starts, then it is up to the user to check manually during the session. So the only issue would be the initial install which after the UAC prompt just restarts Explorer, as told in the README. Yeah, idk, however you put it, some prefer it one way, some the other way...

Not very clear for me: does automatic update means the update performs at the start of the system every time before explorer.exe actually starts? If so - OK, in this case a simple warning message during manual reboot and initial install is quite enough.
But as for now I can see only "notify" and "prompt to install" actions. If so - it looks like explorer.exe will restart - and we are returning to my very first point.

[gjf]

I know how to deal with artifacts, however nobody knows how to dl latest artifact )
Unpacking ep_setup.exe could be the solution... but as far as I see it's not packed. So how to extract it? Any special key with start?

[valinet]

You get the most recent artifact's URL using this:

curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/valinet/ExplorerPatcher/actions/artifacts?per_page=1 | grep archive_download_url

I know how to deal with artifacts, however nobody knows how to dl latest artifact )

You need to specify a random token with no permissions, but it just needs a token apparently:

curl -v -H "Authorization: token $SOME_TOKEN_WITH_OR_WITHOUT_PERMISSIONS"
https://api.github.com/repos/valinet/ExplorerPatcher/actions/artifacts/114175332/zip

You will get a "location" header. In that is a URL which expires in 1 minute which you can use to download the artifact.

As for the executable being "packed"... it's standard resources added to a PE executable. Indeed, not the typical "zip" archive, but still fairly common. idk a quick way to suggest, 7zip weirdly enough does not know how to open it properly. Ofc, if I did it for me, I'd rip off the code from ep_setup already:

• load executable as data file
• FindResourceW with the ID of EP amd64 which is 103
• LoadResource
• LockResource and SizeofResource
• CreateFileW create a file where I will save the DLL, CreateFileMapping, MapViewOfFile, memcpy from address returned by LockResource of size returned by SizeofResource to buffer pointed to by MapViewOfFile (basically memory mapping the output file)
• or using standard library, classic: fopen_s the file where I save with "wb", fwrite from LockResource, number of bytes what SizeofResource returned, to file stream returned by fopen_s; I actually even prefer this more, quicker

Personally, I'd go with writing the above in C. I did the same for various things I needed done in the automated build script. Shell tools are nice, but for complicated things, if you have an idea how to code, it's just faster to fire up a program and have it do what you want... That's what I wanted to ask, I could implement this in ep_setup.exe as well, I thought about this even before when developing it but it wasn't a priority so I postponed it for this time, I could have a method for it to pass some command line switch and have it extract the resources from it, or I can write a small quick program to do just that.

Idk, there are options...

[gjf]

I'd be honest with you: I always think there is no need to do alternatives when the original author implements similar feature. Because alternatives bring complexity and simple changing the original mechanism results in whole crash (as in my case with installer script).

So as you started to develop the own installer - it's better to leave it for you. I just suggested some points but of course if it is too complicated to develop - it's up to you.

Building PS scripts to dl artifacts, develop a full-featured C program to perform the same actions as your installer - but in my own way - I don't think it makes sense.

So let's leave it as is. And I really thank you for this tool and wish you good luck in further development.

And thanks for not kicking me out for such a long discussion ))))

P.S. "And yet it moves" - I was able to update my installer so now it works even with your changes :)
https://github.com/gjf/Windows-11-ExplorerPatcher-Installer/blob/main/Releases/Win11EP.exe

[valinet]

P.S. "And yet it moves" - I was able to update my installer so now it works even with your changes :) https://github.com/gjf/Windows-11-ExplorerPatcher-Installer/blob/main/Releases/Win11EP.exe

See, better to implement yourself. That's also my motto. Even more, I think alternatives should exist, why not, people to extend the work and complement it, that's why I work here on GitHub and not behind closed doors. And like, it's just a matter of extracting the resources from ep_setup.exe and then it's just as before. Indeed, kind of a lengthy discussion, but I know how it goes, I often do the same instead of getting to implementing in which case I finish even faster than if I kept talking.

I suggest you upload the binaries as releases and keep only the source files in the repository, it's easier to browse and see what is going on. It took me while to find the batch file.

Thanks

[gjf]

It was just a tool for myself.
But you are right.
Cleaned the mess and made a correct release.