New Module Proposal: DLL Services

Skip to first unread message

Aaron Klotz

Jul 22, 2021, 1:39:18 PM7/22/21
Hi everybody,

Until now, responsibility for the Windows DLL interceptor and our
Windows dynamic linker instrumentation & blocking has been incorporated
as part of the mozglue module. Given that the code has become much more
complex and with more maintainers, I would like to propose that this
code receives its own distinct module.

This code is currently spread across multiple locations in the tree:
some parts are in mozglue, and others are in toolkit/xre. In conjunction
with the formalization of this module, I would also consolidate this
code into its own self-contained location in the source tree. I'd also
like to create a new corresponding Bugzilla component.

Owner: Aaron Klotz
Peers: Toshihito Kikuchi, David Parks (Interceptor), Molly Howell
Proposed unified source directory: toolkit/xre/dllservices
Proposed Bugzilla Component: Toolkit::DLL Services

Absent any objections, I'll follow through with these changes a week
from today.



Andrew McCreight

Jul 22, 2021, 10:40:44 PM7/22/21
Would the proposed module be part of Core or Toolkit?



You received this message because you are subscribed to the Google Groups "" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Aaron Klotz

Aug 3, 2021, 12:14:21 PM8/3/21
to, Dave Townsend
(+ mossop)

On 7/22/2021 8:40 PM, Andrew McCreight wrote:

Would the proposed module be part of Core or Toolkit?

That's a good (but surprisingly tricky) question!

Uses of DLL services span many areas across the tree:

* The Launcher Process uses DLL services from within firefox.exe;
* Parts of DLL services code needs to reside in mozglue.dll, so that they are accessible to both firefox.exe and xul.dll, as well as other utility programs (such as minidump-analyzer);
* Some of it is invoked during xre startup and already lives in toolkit/xre.

My gut says that *logically* speaking, DLL services should probably live under Core. But in practice, and in the interests of consolidation, I need to pick a single location and go with it, which would leave us with a weird state where the module is in Core but the code is under toolkit/.

Dave, do you have any concerns / suggestions?

Reply all
Reply to author
0 new messages