On Sun, 18 Jun 2006 00:06:33 +0100, Neil wrote:
> Components.classes['@mozilla.org/file/directory_service;1'].getService(Components.interfaces.nsIProperties).get("XpcomLib",
>
> Components.interfaces.nsIFile).path
> actually also evaluates to the wrong location.
Mozilla 1.7.13:
Error: uncaught exception: Permission denied to get property
UnnamedClass.classes
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4)
Gecko/20060612 SeaMonkey/1.0.2
c:\program files\mozilla.org\seamonkey10branch\xpcom.dll
> As it happens, copying xpcom.dll to components/ makes ColorZilla work.
> But what I can't figure out is why ColorZilla is trying to load
> xpcom.dll in the first place...
Running strings on colorzilla.dll gives this:
"ColorZillaModule" @iosart.com/Utils/ColorZilla;1 ColorZilla XpcomLib
@mozilla.org/file/directory_service;1 NS_GetFrozenFunctions xpcom.dll
> If you get a chance before I do, can you try deleting compreg.dat and
> running Mozilla 1.7 under depends.exe to see a) what that expression
> evaluates to b) whether anything tries to load that c) whether it succeeds?
In Mozilla:
00:00:00.640: LoadLibraryA("C:\Program Files\Common
Files\mozilla.org\GRE\1.7.13_2006041307\xpcom.dll") called from
"c:\program files\mozilla.org\mozilla\NSPR4.DLL" at address 0x60F55E6A
by thread 1.
In SeaMonkey:
00:00:11.062: LoadLibraryA("c:\program
files\mozilla.org\seamonkey10branch\xpcom.dll") called from "c:\program
files\mozilla.org\seamonkey10branch\NSPR4.DLL" at address 0x60F77222 by
thread 1.
Naturally the latter fails.
Phil
--
Philip Chee <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]REAL programmers use undocumented DOS calls
* TagZilla 0.059
_______________________________________________
Project_owners mailing list
[email protected]
http://mozdev.org/mailman/listinfo/project_owners
