dependentlibs.list

[UCyborg]

Is there a reason for this file to exist? Last time I checked, operating systems are capable of resolving dependencies of loaded modules on their own. And the only thing that needs to be listed in there for browser to launch is xul.dll, which may as well be a hardcoded dependency of palemoon.exe or whatever.

Though I wonder why both Google and Mozilla go for smaller .exe and then load huge non-optional majority of code as DLL.

Regarding dependentlibs.list, arbitrary DLLs can be put in the browser's folder, listed in the file and the browser will load them without question.

[Moonchild]

Is there a reason for this file to exist?

Absolutely.

Last time I checked, operating systems are capable of resolving dependencies of loaded modules on their own.

Ah but here's the rub: we vendor libraries ourselves in-tree, which end up as libraries in the object dir. Since we link explicitly against those (versions of) those libs (e.g. from the Windows SDK/CRT), we want to make sure our XPCOM glue preloads those libraries and has them registered before any system decides to not search the "current dir" for libraries and pulling them from elsewhere, causing version/API conflicts, type confusion, potential crashes and serious security vulnerabilities in the worst case.

And the only thing that needs to be listed in there for browser to launch is xul.dll, which may as well be a hardcoded dependency of palemoon.exe or whatever.

No, because what exactly is in that list and needs to be preloaded by the glue is entirely dependent on what target you build for. dependentllibs.list is generated at build time using the specific build configuration, O.S. target, etc.

Regarding dependentlibs.list, arbitrary DLLs can be put in the browser's folder, listed in the file and the browser will load them without question.

Yes, and that is exactly by design. I'm not sure why you think that is a problem. If a bad actor has write access to the program dir, then all bets are off, anyway.

[UCyborg]

Oh, well, I've been deleting the supplied CRT DLLs and modifying dependentlibs.list like described so system-wide CRT DLLs would be used for several years. I've been doing that with other programs too (deleting msvc*.dll, ucrtbase.dll, api-*.dll (who needs the last two on Win10?), vcruntime140.dll, vcomp*.dll, maybe one or two other I forgot). I wanted ONE copy in memory at any time.

Maybe it's OCD, maybe I'm control freak, maybe I want to be smarter than everyone else, but it worked. Well, one time Pale Moon crashed on the random website in one of CRT DLLs when I haven't updated Visual C++ redists in a while, that was solved by updating them. I trusted MS those DLLs since Visual C++ 2015 are supposed to be binary compatible anyway.