Closed
Bug 13950
Opened 25 years ago
Closed 25 years ago
NS_InitXPCOM() needs to take directory of component.reg
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
VERIFIED
FIXED
M11
People
(Reporter: dveditz, Assigned: dp)
Details
(Whiteboard: [09271999]waiting to hear from reporter)
Currently when XPCOM is embedded (such as in the install wizard) the component.reg and the components directory end up where the wizard executable is, not where the XPCOM library is. We need to be able to pass in the location of the component registry (that is, where XPCOM itself is), which can then also be used as the base for finding components. (dp says he has a fix already, this is for tracking. When he is checked in then XPISTUB.dll needs to be fixed to pass this, and the wizards must be fixed to pass the dir on to XPISTUB. Looks like the wizards may already pass in this info. Mac does, anyway)
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M11
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 1•25 years ago
|
||
Code fix. Either Dan or Ed Burns can verify this.
Comment 2•25 years ago
|
||
On the Mac, we extract the "core" including xpcomDebug.shlb and the pre-populated "Component Registry" to "Temporary Items" -- a different folder than the Mac Install Wizard itself. Subsequently, we successfully initialize XPCOM; XPInstall and Libjar get loaded as components based on the corresponding entries in the pre-generated "Component Registry". Simply put, it works on the Mac.
It seems to be working fine under Windows too. The native windows installer is able to launch smartupdate and install .xpi files correctly.
Updated•25 years ago
|
Whiteboard: [09271999]waiting to hear from reporter
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 4•25 years ago
|
||
marking verified
You need to log in
before you can comment on or make changes to this bug.
Description
•