Re: [PATCH 5/7] npmshtml: Added Mozilla plugin for mshtml ActiveX controls.
Jacek Caban <jacek(a)codeweavers.com> writes:
I know that this patch is the most questionable. Gecko expects us to give it a DLL named np*.dll, so we can't do it in mshtml. Also, this plugin will be visible to other NPAPI-based browsers running in Wine (that's a matter of change in the next Gecko release), so it's good that it's a tiny wrapper that fails to load if mshtml is not loaded (meaning that we're not running in Wine Gecko).
This prevents the dll registration code from running, since mshtml is not loaded at that point. -- Alexandre Julliard julliard(a)winehq.org
On 12/2/10 12:49 PM, Alexandre Julliard wrote:
Jacek Caban<jacek(a)codeweavers.com> writes:
I know that this patch is the most questionable. Gecko expects us to give it a DLL named np*.dll, so we can't do it in mshtml. Also, this plugin will be visible to other NPAPI-based browsers running in Wine (that's a matter of change in the next Gecko release), so it's good that it's a tiny wrapper that fails to load if mshtml is not loaded (meaning that we're not running in Wine Gecko). This prevents the dll registration code from running, since mshtml is not loaded at that point.
Um, that was stupid from me. I've previously made NP_* function failing, but it didn't work well, so I've changed it to DllMain. I don't see a clean way to fix registration. We could set these registries from mshtml.dll, but then we lose the ability to easily unregister npmshtml.dll. I've sent a patch that checks if it's running from rundll32 or regsvr32 and allows the DLL to load them. I hope it's not too hackish. Jacek
Jacek Caban <jacek(a)codeweavers.com> writes:
Um, that was stupid from me. I've previously made NP_* function failing, but it didn't work well, so I've changed it to DllMain. I don't see a clean way to fix registration. We could set these registries from mshtml.dll, but then we lose the ability to easily unregister npmshtml.dll.
I've sent a patch that checks if it's running from rundll32 or regsvr32 and allows the DLL to load them. I hope it's not too hackish.
I don't think it's a good idea to try to magically fail on DLL load. It would prevent registering from other tools, loading to check version resources, etc. It's preferable to always allow it to load. Of course an even better way would be to change Gecko to make it possible to not have a separate dll at all... -- Alexandre Julliard julliard(a)winehq.org
On 12/2/10 2:23 PM, Alexandre Julliard wrote:
Jacek Caban<jacek(a)codeweavers.com> writes:
Um, that was stupid from me. I've previously made NP_* function failing, but it didn't work well, so I've changed it to DllMain. I don't see a clean way to fix registration. We could set these registries from mshtml.dll, but then we lose the ability to easily unregister npmshtml.dll.
I've sent a patch that checks if it's running from rundll32 or regsvr32 and allows the DLL to load them. I hope it's not too hackish. I don't think it's a good idea to try to magically fail on DLL load. It would prevent registering from other tools, loading to check version resources, etc. It's preferable to always allow it to load.
Agreed, but everything we can do will be some kind of hack. I've found the solution that seems much better. Although Gecko standard plugin directory service doesn't work well for us (the API is in place, it's just used by a high embedding layer in the way that prevents us from using it properly), but there is an environment variable that we can use to specify a custom plugin directory. The only drawback of it is that we need a special directory, but on the other side not having Wine-specific DLL in system directory is a good thing.
Of course an even better way would be to change Gecko to make it possible to not have a separate dll at all...
That's true and it was my initial intention. There was even partial support for such solution in Gecko (called XPCOM plugins), but it was removed from the tree. The only supported way for plugins is NPAPI. Its requirement for DLLs in rooted deep in the code. It means that if we decided to have a Wine-specific changes, we'd have to maintain more changes that I'd like. Integrating it with mainstream may be tricky. Partial solution that would require less Gecko changes is also possible, but it would still be a hack, just living in a different place. Jacek
participants (2)
-
Alexandre Julliard -
Jacek Caban