Unload shell extension
Jens Gruschel
menu, the Explorer loads my DLL the first time it is required (when the
user rightclicks a file of a certain type). Is there a way to unload
this DLL other than killing explorer.exe or rebooting Windows?
--
Jens Gruschel
http://www.pegtop.net
Nigel Thomas
"Jens Gruschel" <nos...@thisurldoesnotexist.com> wrote in message
news:4854e92a$1...@newsgroups.borland.com...
> After registering a shell extension for the Windows Explorer context
> menu, the Explorer loads my DLL the first time it is required (when
> the user rightclicks a file of a certain type). Is there a way to
> unload this DLL other than killing explorer.exe or rebooting
> Windows?
You can use regsvr32.exe to unload it:
regsvr32.exe /u mydll.dll
Provide the full path to your DLL if necessary.
Nigel
Jens Gruschel
>
> regsvr32.exe /u mydll.dll
Sure? I ask because I didn't register it that way. I just added an entry
to HKEY_CLASSES_ROOT\CLSID and some other keys. So I guess Windows
Explorer does a simple LoadLibrary when my DLL is required. I thought
maybe there is a way to let Explorer do a FreeLibrary. Anyway, calling
regsvr32.exe that way gives me a message that the operation was
successful, but I still cannot delete my DLL afterwards (I can after
killing explorer.exe).
Rob Kennedy
> After registering a shell extension for the Windows Explorer context
> menu, the Explorer loads my DLL the first time it is required (when the
> user rightclicks a file of a certain type). Is there a way to unload
> this DLL other than killing explorer.exe or rebooting Windows?
Explorer has to be terminated. You don't have to kill it or reboot, though.
Pretend as though you're going to reboot. Then hold Ctrl+Alt+Shift and
press Cancel on the shutdown dialog. That closes Explorer. When you're
ready (say, after recompiling your DLL), start a new Explorer instance
with Task Manager.
--
Rob
Jens Gruschel
> press Cancel on the shutdown dialog. That closes Explorer.
Good to know. Thanks a lot, Rob!
> When you're
> ready (say, after recompiling your DLL), start a new Explorer instance
> with Task Manager.
That's what I've done before. A bit cumbersome, but it works. And I
found out that while recompiling the DLL frequently, making Windows
start a new process for each Explorer window is a good idea.
For development of my DLL that's alright, but my main problem remains:
after installation on a customer's PC, maybe from time to time I want to
replace the DLL with an auto updater. I guess there's no alternative
than waiting for a restart of Windows, if I don't want to annoy my
customers with terminating Windows Explorer.
Remy Lebeau (TeamB)
> after installation on a customer's PC, maybe from time to time
> I want to replace the DLL with an auto updater.
If the DLL is in use, it can't be repleased right away. You will have to
wait until the next reboot. Use MoveFileEx() with the
MOVEFILE_DELAY_UNTIL_REBOOT flag for that. Move installers have an option
for replacing in-use files by using suvh an approach internally.
> I guess there's no alternative than waiting for a restart of Windows
Not really.
Gambit
Remy Lebeau (TeamB)
> Sure? I ask because I didn't register it that way. I just added an
> entry to HKEY_CLASSES_ROOT\CLSID and some other keys.
You should not have done that manually at all. Using regsvr32.exe is the
official way to register/unregister ActiveX controls and servers. It calls
the DllRegisterServer() and DllUnregisterServer() functions that ActiveX
DLLs are required to export. Those functions manage the Registry keys for
you.
> So I guess Windows Explorer does a simple LoadLibrary
> when my DLL is required.
It is a little more complicated than that. You have to register your DLL
first, and then the OS can use CoCreateInstance() when it needs to access
the ActiveX control that your DLL implements. But yes, ultimately
LoadLibrary() is used to load your DLL into memory.
> I thought maybe there is a way to let Explorer do a FreeLibrary.
It will do that automatically when it is done using the DLL.
> Anyway, calling regsvr32.exe that way gives me a message that
> the operation was successful, but I still cannot delete my DLL
> afterwards
Because the DLL is still in use. Calling regsvr32 simply removes the
Registry keys for the DLL, but does not instruct the OS to release the DLL
from memory if it is already being used.
> I can after killing explorer.exe
There is a delay before the OS releases unused shell extensions, in case
they need to be used again.
Gambit
Jens Gruschel
>> entry to HKEY_CLASSES_ROOT\CLSID and some other keys.
>
> You should not have done that manually at all. Using regsvr32.exe is the
> official way to register/unregister ActiveX controls and servers.
Thanks for that hint. I guess I still have to add the shellex subkey
manually to the registry for the required file types, right?
> There is a delay before the OS releases unused shell extensions, in case
> they need to be used again.
Looks like the delay is pretty long.
Jens Gruschel
> wait until the next reboot. Use MoveFileEx() with the
> MOVEFILE_DELAY_UNTIL_REBOOT flag for that.
Yes, I know, but I thought maybe I could undo the usage somehow. Anyway,
thank for your help, excellent as always!
Remy Lebeau (TeamB)
> I guess I still have to add the shellex subkey manually to the registry
> for the required file types, right?
Yes, but you should do it inside your DLL's code, not by hand. Let regsvr32
call your DLL's exported DllRegisterServer() and DllUnregisterServer()
functions normally. From there, you can add/remove whatever extra Registry
keys you need.
> Looks like the delay is pretty long.
Several minutes, yes.
Gambit
Jens Gruschel
> call your DLL's exported DllRegisterServer() and DllUnregisterServer()
> functions normally. From there, you can add/remove whatever extra Registry
> keys you need.
Currently I'm using the ComServ unit, which implements DllRegisterServer
and DllUnregisterServer. Should I replace these procedures by my own
ones or is there another way?
Jens Gruschel
> and DllUnregisterServer. Should I replace these procedures by my own
> ones or is there another way?
Never mind, I just noticed the virtual method UpdateRegistry of
TComObjectFactory :-)
Remy Lebeau (TeamB)
> Currently I'm using the ComServ unit, which implements DllRegisterServer
> and DllUnregisterServer. Should I replace these procedures by my own ones
> or is there another way?
If you study their code more closely, you will see that they both call the
the UpdateRegistry() method of every TComObjectFactory-based classed in your
DLL. TComObjectFactory.UpdateRegistry() is virtual, so you can override it
in the factory for your particular ActiveX object.
Gambit
Martin Stoeckli
For working on your computer, you can also set a registry entry, so
Windows will load your library for each explorer process separately and
releases it afterwards.
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer]
"DesktopProcess"=dword:00000001
Creating the entry "DesktopProcess" and setting it's value to "1" allows
to debug your extension, you then can use Explorer as the start
application (the setting takes effect after the next reboot).
Hope this makes you life a bit easier,
Martin
Jens Gruschel schrieb:
> <snip>
>
> For development of my DLL that's alright, but my main problem remains:
> after installation on a customer's PC, maybe from time to time I want to
> replace the DLL with an auto updater. I guess there's no alternative
> than waiting for a restart of Windows, if I don't want to annoy my
> customers with terminating Windows Explorer.
--
Martin Stoeckli
http://www.martinstoeckli.ch/delphi
Jens Gruschel
> wait until the next reboot. Use MoveFileEx() with the
> MOVEFILE_DELAY_UNTIL_REBOOT flag for that. Move installers have an option
> for replacing in-use files by using suvh an approach internally.
I hope I don't waste too much of your time, but I have one more
question: My shell extension is closely related to some application of
mine, in fact it just feeds the application with file names. What's the
best place to install my DLL to? The Windows system folder or my
application folder? I found pros and cons for both:
pros for system folder:
* DLL is a shell extension and Explorer belongs to the system
* uninstallation is probably easier because the application folder can
be deleted while the DLL is still waiting for "MOVEFILE_DELAY_UNTIL_REBOOT"
cons for system folder:
* DLL requires the application and therefore belongs to it
* there are more than enough files in the system folder already
Or is there another, better location for such a DLL? What do you think?
Remy Lebeau (TeamB)
> I hope I don't waste too much of your time, but I have one
> more question: My shell extension is closely related to some
> application of mine, in fact it just feeds the application with
> file names. What's the best place to install my DLL to?
The application's folder. The DLL is not being shared with any other
application, so it doesn't need to be placed anywhere else.
> pros for system folder:
> * DLL is a shell extension and Explorer belongs to the system
The DLL is an ActiveX/COM object, so the actual location is not an issue.
The registration for the DLL will tell the OS exactly where to find the DLL
when needed.
> cons for system folder:
The system folder requires admin rights in order to access that folder. So
only an admin would be able to install/uninstall your DLL.
Gambit
Jens Gruschel
> only an admin would be able to install/uninstall your DLL.
That's not a problem, and one needs similar rights to install files to
the programs folder. But I got your point, thanks again, Gambit.