{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreictxh3mv3mf3y45nrju7nwojyhjxkihishzhlwsnajss6wdqsbjnu",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mhipbnzw4vu2"
  },
  "path": "/viewtopic.php?t=33253&p=271266#p271266",
  "publishedAt": "2026-03-20T14:14:02.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> Is there a reason for this file to exist?\n\nAbsolutely.\n\n\n> Last time I checked, operating systems are capable of resolving dependencies of loaded modules on their own.\n\nAh 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.\n\n\n> 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.\n\nNo, 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.\n\n\n> 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.\n\nYes, 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.\n\n* * *",
  "title": "Platform Development • Re: dependentlibs.list",
  "updatedAt": "2026-03-20T14:14:02.000Z"
}