3
NewbieNewbie
3

    Mar 19, 2013#16

    Mofi wrote: It is of course possible to do the unregister of the shell extension DLL(s) with the uninstaller for the current user account. That would make the uninstall a little bit cleaner for computers with a single user account. For computers used by multiple users, there is most likely no chance that an uninstaller unregisters the shell extension for all user accounts.
    You might have not understood what I described in previous post.
    I will try to explain ti more clearly, in details.

    The thing is that there is no need for additional implementation, workaround in the installer to perform cleanup. Of course, also as you have mentioned, due to it will not remove this for all users, but only for logged in user.

    For example - If you install WinZip under system account or login with another user, there is no WinZip Shell Extension visible on right-click, until you first run WinZip application. So the behavior is the same as UltraEdit does. But if you simply delete shell extension DLL file or perform uninstall of WinZip under system account, then "WinZip" shell extension automatically hidden by Windows - for all users - and this is without extra cleanup, HKCU registries are still in place, only DLL file that registries are pointing to is removed.
    It is simply as just 5 minutes to check and a WinZip trial is easy downloadable. There of course may be other software that also properly manages shell extensions. This just proves that there is no need for extra magic to do it. Another example of the same behavior is "Git" application. I'm sure there are plenty of another apps that also properly make their shell extensions.

    Of course I would not complain and discuss this if same behavior of User shell extensions was in other applications. But since there is no such a problem with other Apps under the same conditions - this leads to the conclusion that "UltraEdit" developers team made it wrong.

    I also have send this to the support team, so waiting till they comment on this.

    6,683583
    Grand MasterGrand Master
    6,683583

      Mar 19, 2013#17

      Okay, now I understand the scenario and evaluated it with following steps:
      • I started UltraEdit on Windows 7 x64, opened Advanced - Configuration - File Associations, checked the setting Integrate with Explorer as with the string &UltraEdit, closed the configuration dialog with button OK and exited UltraEdit.
      • I clicked with right mouse button on a file in Windows Explorer and could see UltraEdit in context menu. So the file ue64ctmn.dll in UltraEdit program files directory is now loaded by Windows Explorer x64.
      • I clicked with right mouse button on a file in Total Commander x86 and could see UltraEdit in context menu. So the file ue32ctmn.dll in UltraEdit program files directory is now loaded by Windows Explorer x86.
      • I tried to move the 2 DLLs to a different directory which of course failed as DLLs currently loaded by any application cannot be replaced, moved or deleted.
      • I restarted Windows 7 and opened first Total Commander (configured on my computer to be automatically started on Windows startup). Now I could move both DLLs because whether 32-bit nor 64-bit Windows Explorer have loaded them at this time.
      • I clicked with right mouse button on a file in Windows Explorer and could NOT see UltraEdit in context menu. That's what you want. If the DLL is not present anymore and therefore Windows Explorer can't load it, the context menu item should not be displayed anymore.
      • I clicked with right mouse button on a file in Total Commander x86 and could NOT see UltraEdit in context menu. So same behavior for the 32-bit shell extension as for the 64-bit shell extension.
      • I moved the 2 DLLs back into the UltraEdit program files directory.
      • On next opening the context menus in Windows Explorer and Total Commander x86 for any file results again in showing UltraEdit in context menu.
      In other words there is no difference to behavior as you described for WinZip as long as a still registered UltraEdit shell extension DLL is really deleted during uninstall process.

      So the UltraEdit uninstaller has to handle 2 situations for both shell extension DLLs:
      1. The shell extension DLL is not loaded by Windows Explorer while running the UltraEdit uninstall because user has not enabled Explorer integration (since last Window start) and therefore the DLL can be immediately deleted.
      2. The shell extension DLL is loaded currently by Windows Explorer and therefore deleting the DLL file is not possible. The uninstaller must add in this case the file to the pending rename operations for next Windows start so that the file is deleted by Windows before Windows Explorer is started the next time.
      I don't know if the second scenario with deletion of the DLL with pending rename operation after uninstall of UltraEdit and restart of Windows really works as I have never tried this scenario on my computers in the last 3 years.

      Manually unchecking the setting Integrate with Explorer as in UltraEdit before exiting UE the last time and uninstall UE does not result in an immediate deletion of the shell extension DLLs during uninstall process as Windows Explorer, once has loaded a shell extension DLL, does not unload it, even if the registration for the DLL is not present anymore in the registry. As far as I know it is necessary to restart Windows to force an unload of the shell extension DLL to be able to delete the DLL (or update it).

      Read more posts (-13 remaining)