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

Status: RESOLVED INVALID

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[Adam Lock]

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.

Comment 1

[Adam Lock]

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

[Benjamin Smedberg]

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

[locka]

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.

Comment 4

[Adam Lock]

Attachment: 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.

Comment 5

[Adam Lock]

Attachment: 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.

Comment 6

[Adam Lock]

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.

Comment 7

[Ed Morley [:emorley]]

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

[Filter bugspam on activexinvalid]