[ActiveX / AxPlugin] Reduce runtime dependencies on control & plugin

RESOLVED INVALID

Status

Core Graveyard
Embedding: ActiveX Wrapper
RESOLVED INVALID
15 years ago
6 years ago

People

(Reporter: Adam Lock, Unassigned)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

17.64 KB, patch
Alexandre Trémon
: review+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
The checkin for bug 206901 moved some shared classes out of
mozilla/embedding/activex/src/control into mozilla/embedding/activex/src/common
where they are built as a static lib.

I discovered in the process of this that I couldn't link the same static lib to
the control and the plugin because one used XPCOM glue and the other did not.
Therefore I temporarily disabled XPCOM glue in the plugin so the lib could be
shared. 

This bug is to enable XPCOM glue again in the common lib, the plugin and in the
control. The control touches some internal interfaces, so some cleanup may be
required in the control to make it happy. It would also be worthwhile to remove
its dependency on nspr at the same time. I am also concerned that having a NPAPI
plugin depend on xpcom.dll is not a good thing and I have yet to verify it works
in GRE mode.
(Reporter)

Comment 1

15 years ago
On second thoughts, I'm not sure it is possible to rely on just XPCOM glue. I
spent some time trying to enable glue and disable other libs in the control and
the plugin, but both directly or indirectly need functions in XPCOM such as
NS_NewByteArrayInputStream. I could beat these linker errors down one by one
(e.g. link to xpcom_io_s.lib for the last one), but I'm wary of the bloat that
will introduce.

So I'm going to see if I can link to glue for some stuff and the normal
xpcom.dll for the rest, thereby minimizing at least some of the dependencies,
even if I can't remove them completely.

I also discovered that the nspr dependency is necessary because nsVoidArray is
pulled in. I'm not so concerned with that if xpcom.dll is being needed anyway.

Comment 2

15 years ago
adamlock: nsByteArrayInputStream should really be available on a contractID so
that you can createInstance() it rather than linking to xpcom. nsVoidArray is a
trickier problem, unfortunately.

Comment 3

15 years ago
I'm not sure what is creating the byte array. I know it's not my code, so I
would guess something is inlining it somewhere.

Anyway this is a just example of the whack a mole, that I was describing. I
think my current tack is just is to remove as many unecessary dependencies and
see where that leaves me. STL is high on the list too so I'll rename this bug to
reflect its more general goal.
Summary: [ActiveX / AxPlugin] Enable XPCOM glue once more → [ActiveX / AxPlugin] Reduce runtime dependencies on control & plugin
(Reporter)

Comment 4

15 years ago
Created attachment 125770 [details] [diff] [review]
Patch to remove STL

Patch removes last vestiges of STL, removing the runtime dependency. Also
contains some cleanup and removes ActiveXTypes.h and the not very useful macros
it contains.
(Reporter)

Comment 5

14 years ago
Created attachment 146047 [details] [diff] [review]
Patch

Updated patch. It doesn't do as much of the last one (i.e. doesn't completely
remove STL) but prepares the ground and remove some legacy cruft and types.
Also fixes character conversion macros to use the const form where appropriate,
eg W2T becomes W2CT etc.
Attachment #125770 - Attachment is obsolete: true
(Reporter)

Comment 6

14 years ago
Comment on attachment 146047 [details] [diff] [review]
Patch

Alex, can you review this? Mainly it is macro fixes, removing a bogus CIPtr()
macro that was needed for VC5 and fixing some character conversion calls. I
will follow-up with another patch to remove STL completely and cut a 400k DLL
dependency in the process.
Attachment #146047 - Flags: review?(atremon)

Updated

14 years ago
Attachment #146047 - Flags: review?(atremon) → review+
QA Contact: dunn5557 → activex

Comment 7

7 years ago
The ActiveX embedding API was removed in bug 662023 and friends, making this INVALID.

[Filter bugspam on activexinvalid]
Assignee: adamlock → nobody
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
(Assignee)

Updated

6 years ago
Component: Embedding: ActiveX Wrapper → Embedding: ActiveX Wrapper
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.