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.
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.
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.
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
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.
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
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)
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
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.