Allow loading of Macho oldstyle (npapi) plugins.



17 years ago
17 years ago


(Reporter: sfraser_bugs, Assigned: sfraser_bugs)




(1 attachment)



17 years ago
We currently assume that plugins using the old-style NPP apis are CFM, and, if
you try to make a Macho one, we'll crash when it tries to call back via CFM

I don't see any reason not to suppport old-style MachO plugins; we need it for
the default plugin (bug 166998), for one.

Comment 1

17 years ago
Created attachment 104230 [details] [diff] [review]
patch to allow loading of old-style Macho plugins

This patch allows the loading of Macho plugins by:
1. requiring that such plugins use a main entry point named "mainMachO"
2. not wrapping the function pointers for such plugins (both plugin and
   netscape tables) with T-Vector glue.

Is requiring a different entry point name a good thing? NSPR can't tell us what
the format of the library is (suckage), so this seems like a reasonable

Comment 2

17 years ago
cc wtc who may wish to comment on the inability to determine the format of a
library (CFM vs. Macho) given a PRLibrary*.

Comment 3

17 years ago
Simon, I don't know what you want me to say.
Do you want me to confirm the inability to
determine the format of a library given a
PRLibrary*, or do you want me to add a function
to determine that?

Mac is the only platform on which there are
multiple executable formats of dynamic load
libraries.  NSPR seldom provides a function
that's only useful on one platform. It should
be simple to add such a function though because
the format of a library is stored in the
PRLibrary structure.

Comment 4

17 years ago
I'm going to WONTFIX this. The plugin API specifies that plugin entry points are
CFM TVectors, so MachO plugins will have to provide compatible function
pointers. See the patch in bug 166998 for the default plugin for an example of
how to do this.
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.