On Monday, July 14, 2003, at 08:54 AM, Doug Turner wrote:
Kevin,
Have you looked at the "docs"? http://www.mozilla.org/projects/embedding/GRE.html
Yes, but I admit it was a little while back. I read through it again and I see that some info about XPCOMGlue has been added since I last checked. I decided to try using XPCOMGlue again, linking with the Gecko SDK, and after some googling was successful in getting it to build and run against 1.4. However, it expects to find all the necessary sub-directories (i.e. "chrome", "plugins", etc.) inside the Python root directory. I know I can change this with NS_InitEmbedding, but I don't see any way currently to do so using XPCOMGlue. In any case, I can go through and tweak our build process to use XPCOM_GLUE if the user defines it as this would work fine for C++ apps.
I'm assuming the problem I'm experiencing linking against xpcom.lib with 1.4 final is that it is using XPCOM_GLUE itself and thus only has the NS_InitXPCOM2, NS_ShutdownXPCOM, etc. functions instead of the NS_InitEmbedding, etc. functions. (In other words, if I want to use 1.4 I'll have to rebuild turning off XPCOM_GLUE.) Since the new XPCOM library is so small, would it be possible to simply add those five functions into xpcomglue.lib and allow people to thus avoid xpcom.dll altogether? That way, the old xpcom.dll would be available to clients using NS_InitEmbedding.
One other question related to Windows embedding; is it possible to have NSPR libraries installed into the Windows\system folder?
Yes, but as you know that is not advisable.
What I'd like to do is move towards not having to add things to the user's PATH to get wxMozilla Python bindings to run. I don't know how often the NSPR libraries change, but if they do remain relatively stable this would allow people to utilize GREs that are not in the current directory without setting the PATH.
Recently, we had to ensure that the NSPR libraries were next to the embedding application because some Netscape Server product shipped a copy of NSPR and put it in the c:\windows directory. This directory is read before libs in the user's path. (check out msdn for all the details of search paths). Although, most people don't run Netscape Server products, it is just an example of an application causing you embedding application to fail/crash.
I hope, eventually, to remove the xpcom-glue dependency on NSPR. If we get to that point, it might be possible to fix this problem though some kind of dependent library fix that I added to XPCOM recently.
This would be great! I can live with setting the PATH for now, but its good to know that this could be resolved. =)
Thanks for your help!
Kevin
