On 12/2/10 2:23 PM, Alexandre Julliard wrote:
Jacek Cabanjacek@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