I've changed the code not to use COM. Now it loads a DLL and searches for a GetIntegrationObject entry point. That function returns structures with a pointer to the ops structure. This is similar to how GDI objects are implemented. One could also export all the function from the DLL and build the ops structs on the client side (like it is done in GDI/User drivers) but that would require more code to be written and make it harder to forward all the unhandler objects from e.g. the kde driver to the freedesktop driver - we would need to add entry point forwarding every time we add a new functions to the freedesktop driver. Is this approach good? Mikolaj Zalewski
Mikołaj Zalewski wrote:
I've changed the code not to use COM. Now it loads a DLL and searches for a GetIntegrationObject entry point. That function returns structures with a pointer to the ops structure. This is similar to how GDI objects are implemented. One could also export all the function from the DLL and build the ops structs on the client side (like it is done in GDI/User drivers) but that would require more code to be written and make it harder to forward all the unhandler objects from e.g. the kde driver to the freedesktop driver - we would need to add entry point forwarding every time we add a new functions to the freedesktop driver. Is this approach good?
I don't think it is. I think it would be better to start off with by just doing the shell integration in shell32. If a framework like this is needed, then it will become obvious later on. -- Rob Shearman
Robert Shearman wrote:
I don't think it is. I think it would be better to start off with by just doing the shell integration in shell32. If a framework like this is needed, then it will become obvious later on.
That's true that I currently don't need it but if someones would need a really tight integration with a desktop environment he might need to load the enviroment's libraries. By keeping things in separate DLLs we can easly not load the libraries if the user don't use that desktop and not build the DLL is the libraries are not present. Also there were reports about running wine under MacOS X which, I guess, doesn't comply to freedesktop.org. So with a separate DLL it would be easier for them to see which code they don't need. But of course all that can be also done if all the code goes to shell32. I only thought that having separate DLLs is a cleaner approach. If it is not considered so I can change it. Mikolaj Zalewski
On Thu, Jun 15, 2006 at 11:26:02AM +0100, Robert Shearman wrote:
I don't think it is. I think it would be better to start off with by just doing the shell integration in shell32. If a framework like this is needed, then it will become obvious later on.
That's why I like the idea of using COM. All the infrastructure is already there. For now we can implement the trash shell object inside shell32 and if someone wants to write a OS/X version all they need to do is override a registry key. Other shell integration objects can even be implemented out-of-proc in the explorer process all this can be cleanly hidden from the shell32 code that uses it. /Ulrich
On Fri, 16 Jun 2006 08:54:04 -0400, Ulrich Czekalla wrote:
That's why I like the idea of using COM. All the infrastructure is already there. For now we can implement the trash shell object inside shell32 and if someone wants to write a OS/X version all they need to do is override a registry key. Other shell integration objects can even be implemented out-of-proc in the explorer process all this can be cleanly hidden from the shell32 code that uses it.
Out of process COM is never cleanly hidden; if nothing else it can cause unexpected threads to be created and unexpected re-entrancy via the implicit message loops. Given that we already have platform specific handling infrastructure in the form of the configure script, it could be as simple as having a conditional Makefile that compiles functions with magic names. thanks -mike
participants (4)
-
Mike Hearn -
Mikołaj Zalewski -
Robert Shearman -
Ulrich Czekalla