XPCOM installation folders when using dependent DLLs? - Mozilla

This is a discussion on XPCOM installation folders when using dependent DLLs? - Mozilla ; Hi, I'm a Mozilla/XPCOM newbie building a C++ XPCOM DLL with version 1.8 of the Gecko SDK targeting Windows XP and using Visual Studio 2008. Up to now, my installation procedure has been: 1. Copy the built .xpt and component ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: XPCOM installation folders when using dependent DLLs?

  1. XPCOM installation folders when using dependent DLLs?

    Hi,

    I'm a Mozilla/XPCOM newbie building a C++ XPCOM DLL with version 1.8
    of the Gecko SDK targeting Windows XP and using Visual Studio 2008. Up
    to now, my installation procedure has been:

    1. Copy the built .xpt and component dll to \Program Files\Mozilla
    Firefox\components.
    2. In the \Program Files\Mozilla Firefox\components folder, run
    regxpcom -x . from the SDK.
    3. In my profile folder, delete compreg.dat and xpti.dat.

    Then I am able to start firefox using that profile and load my test
    javascript and exercise the XPCOM component.

    Now I need to add in two third party DLLs to my component DLL. I've
    read https://developer.mozilla.org/en/Usi...ion_Components,
    plus the SDK/VS-specific thread at http://forums.mozillazine.org/viewto...f=19&t=1234165.
    But I'm still confused about what folders various pieces are supposed
    to live in, and how I go about registering the component.

    From reading the docs, it looks like this is what's supposed to
    happen:

    \Program Files\Mozilla Firefox\components now doesn't have any pieces
    of my install
    \Program Files\Mozilla Firefox\extensions\{some-guid}\components has
    my .xpt file and my stub DLL
    \Program Files\Mozilla Firefox\extensions\{some-guid}\libraries has my
    real DLL, plus my third party DLLs

    Then I run regxpcom -x . in \Program Files\Mozilla Firefox\extensions\
    {some-guid}\component, delete compreg.dat and xpti.dat out of my
    profile, and then I should be able to run firefox and exercise my
    revised XPCOM component. Right? Or am I missing something here?

    Thanks in advance,

    Polly



  2. Re: XPCOM installation folders when using dependent DLLs?

    Tom and Benjamin,

    Thanks to both of you for your replies. As befits my newbie status, I
    knew hardly any of this. :^)

    I took Benjamin's advice about validating the new locations with a
    version of my DLL that didn't have dependent DLLs first, but ran into
    problems with that. First, I built a standalone version of my DLL, and
    copied that and my XPT file into \Program Files\Mozilla Firefox
    \components, deleted the compreg.dat and xpti.dat out of my profile,
    and executed my test javascript. This worked fine, so I know that my
    DLL and my XPT files are sane.

    I then removed my DLL and XPT files from \Program Files\Mozilla
    Firefox\components, and created a folder called \Program Files\Mozilla
    Firefox\extensions\{a-guid}, where a-guid is the value of my component
    CID as a string. I put my install.rdf in the folder, and underneath
    that, I created libraries and components. I put my XPT in libraries
    and my (standalone) DLL file in libraries. I deleted compreg.dat and
    xpti.dat from the profile, and started Firefox. When I started up, I
    saw the add-ons dialog indicating that one new add-on had been
    installed, but when I loaded my test javascript, it wouldn't resolve
    Components.classes[cid]. I also tried copying my standalone DLL
    directory into the components sub-folder, with the same error
    message.

    Any ideas on where I'm going wrong with the new locations? I'm running
    the XP 3.5.2 standard binaries.

    Tom, you asked what third party DLLs I'm using -- it's the openssl
    DLLs ssleay32.dll and libeay32.dll. I'll give copying them directly
    into \windows\system32 a try, since I believe I will have
    administrative access to my target machines.

    Many thanks,

    Polly


  3. Re: XPCOM installation folders when using dependent DLLs?

    On Aug 19, 2:33*pm, Benjamin Smedberg wrote:
    > On 8/19/09 5:09 PM, Polly wrote:
    > You don't want {a-guid} to be your component CID. Instead, you want it tobe
    > the "extension ID" in install.rdf (the value within ). Although I'm
    > not sure whether this is the cause of your problem or not.


    Yes, this was it. It loads perfectly now!

    > > Tom, you asked what third party DLLs I'm using -- it's the openssl
    > > DLLs ssleay32.dll and libeay32.dll. I'll give copying them directly
    > > into \windows\system32 a try, since I believe I will have
    > > administrative access to my target machines.

    >
    > If that solution works for you, it's certainly easier than doing just a
    > Firefox extension, although it will definitely require administrator access.


    Copying the .dll's into system32 worked great, and let me move ahead
    and validate the rest of my code. Kudos to Tom for pointing this out.
    However, I do think it would be a nicer solution to *not* write into
    system32, and I think I'm pretty close, so I'm going to see if I can
    make a non-admin stub solution work.

    Again, thanks to you two for responding with such helpful advice.

    Polly

  4. Re: XPCOM installation folders when using dependent DLLs?

    On Aug 20, 1:33*am, Neil wrote:
    > Polly wrote:
    > >Tom, you asked what third party DLLs I'm using -- it's the openssl DLLs ssleay32.dll and libeay32.dll.

    > One possible alternative might be to rewrite your code to use NSS?


    Hi Neil,

    Thanks for the suggestion. As it happens, my requirements were for
    using AES, and it was my understanding that NSS's functionality is
    exposed in Firefox via PSM, and that PSM doesn't presently support
    AES. But as I said, I'm pretty wet behind the ears with Firefox, and
    would love to hear from more experienced devs if I've got this wrong.

    Polly


+ Reply to Thread