Is RestartManager broken?

[Zoë Peterson]

Hi All,

We're shipping an Explorer context menu extension, and I wanted to try
using RestartApplications, but across bunch of different test
systems/VMs, it seems to just not work reliably?  On my dev PC (Windows
11 23H2) Explorer's UI goes away but the process continues running in
the background and InnoSetup can't continue.  My clean Windows 10,
Windows 11 21H2, and 22H2 VMs all worked ok, but my clean Win11 23H2 VM
failed, and a separate non-dev laptop failed the same way.  I asked the
rest of our team and the general sense was that even doing things like a
TortoiseSVN upgrade, where they're using an MSI instead of InnoSetup
results in similar behavior about half the time.

Is anyone using the restart manager successfully for shell extensions
and not having it make the UI unusable?  Is there some trick to it?

Thanks,
Zoë Peterson
Scooter Software

[Bill Stewart]

It's a good question; I don't know the answer, unfortunately.

It seems that RM just does not work reliably for Explorer context menu extensions. This would seem to be another example:

http://www.classicshell.net/forum/viewtopic.php?p=6131

[Zoë Peterson]

On 9/30/2024 1:10 PM, 'Bill Stewart' via innosetup wrote:
> It's a good question; I don't know the answer, unfortunately.
>
> It seems that RM just does not work reliably for Explorer context menu
> extensions. This would seem to be another example:
>
> http://www.classicshell.net/forum/viewtopic.php?p=6131

In that case, do you see anything wrong with my planned workaround?

All Users install relies on the existing
restartreplace/uninsrestartdelete behavior.

Current User install:
1) Have two [Files] entries, one to the original filename and one where
DestName includes a '.pending' suffix
2) Add a Pascal scripting function that toggles between the two based on
whether the file exists, has a different version number than the
incoming one (GetPackedVersion/SamePackedVersion), and can be opened for
writing (via CreateFile(GENERIC_WRITE))
3) Set up a Windows HKCU [Run] registry entry to run one of our apps
with a custom flag when the user logs in.  If the flag is detected, use
MoveFile to try to replace the files with the .pending versions.  If
that succeeds, remove the [Run] entry.

For (2), it seems like this would be better handled via some sort of
PasScript callback from
PerformInstall.ProcessFileEntry.DoHandleFailedDeleteOrMoveFileTry?

For (3), I'd prefer to use [RunOnce] instead, but if the user logs in
and right clicks before our helper launches, it needs to try again the
next time.  I could disable the extension after the install until the
replace succeeds, but the extension is written expecting it might be out
of date relative to the rest of the app, and I'm trying to avoid being
too disruptive if users are in the middle of something.

If there's a better way to approach any of this, I'd love to hear it.

Thanks again,
Zoë Peterson
Scooter Software

[Jordan Russell]

On 9/30/24 3:39 PM, Zoë Peterson wrote:
> If there's a better way to approach any of this, I'd love to hear it.

Are you aware that in-use files can be renamed? This should succeed:

ren your.dll your.dll.old
ren your.dll.new your.dll

Processes that have the old DLL loaded will continue to use it, while
new processes will load the new DLL. If a process that has the old DLL
loaded calls LoadLibrary("your.dll") a second time, the reference count
should just be incremented; it won't result in both versions being
loaded at the same time in the same process.

The ".old" suffix actually shouldn't be fixed, because multiple old DLLs
could accumulate if the user upgrades the app 2+ times without logging
out. (3 processes could potentially have 3 different versions of the DLL
loaded -- which requires 3 different file names.)

-JR