4422 - 68K plugin support needs to be removed for carbon compliance

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

The Mixed-Mode Manager in Carbon (even under OS8.5) is going away. We need to
remove references to CallUniversalProc() and NewRoutineDescriptor() from the code
because they are not available any more.

This means no 68K plugins. amusil thinks this is an ok requirement.

Comment 1

[sujay]

Eli, I'm re-assigning you these Mac bugs to take ownership. These are
Greg's old bugs...

Comment 2

[Alex Musil]

Pink - is our plan to be carbon compliant with the initial rev of seamonkey?

Comment 3

[Mike Pinkerton (not reading bugmail)]

It would be nice to be pretty close. It's not the end of the world if we're not,
but it would make my life much easier if I didn't have to carry around a lot of
#ifdef-d code in my tree.

Comment 4

[Eli Goldberg]

Shrirang is now QA owner for Plug-ins; QA assigning all of my Plug-ins bugs over
to him.

Comment 5

[rickg]

non-essential for m16

Comment 6

[av (gone)]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 

Comment 7

[Mike Pinkerton (not reading bugmail)]

assigning to beard just so that it doesn't fall off the radar.

Comment 8

[Patrick C. Beard]

At least conditionally dropped, when running under Mac OS X. However, since the 
Quicktime plugin still has a 68K entry point (last time I looked) we probably 
still need this support in Mac OS 9.

Comment 9

[Gary L. Wade]

If we want to be compatible with Microsoft Internet Explorer and its Carbon 
implementation (and, therefore, simplify things for our developers), then we 
should support the plug-in filetype 'IEPL' (Netscape got in first for browser 
plug-ins, but Microsoft got in first for Carbonized plug-ins), which is used to 
denote a Carbonized plug-in.  All entry points for that type of plug-in are 
merely function pointers without any use of UPPs.

Comment 10

[Steve Dagley]

I'm marking this as fixed as I know Patrick has plugins working in the carbon 
these days

Comment 11

[shrirang khanzode]

taking sdagley's word and marking Verified :)

Comment 12

[Patrick C. Beard]

Just to clarify Gary Wade's comment, 'IEPL' is no longer the standard plugin file 
type, rather Apple has specified 'BRPL' instead. It also turns out that the 68K 
and the Carbon way to handle callbacks are identical. The current interfaces 
reflect that.