{"id":17543,"date":"2009-07-10T10:00:00","date_gmt":"2009-07-10T10:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2009\/07\/10\/if-dynamic-dll-dependencies-were-tracked-theyd-be-all-backwards\/"},"modified":"2009-07-10T10:00:00","modified_gmt":"2009-07-10T10:00:00","slug":"if-dynamic-dll-dependencies-were-tracked-theyd-be-all-backwards","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20090710-00\/?p=17543","title":{"rendered":"If dynamic DLL dependencies were tracked, they'd be all backwards"},"content":{"rendered":"

Whenever the issue of DLL dependencies arises, I can count on somebody arguing that these dynamic dependencies should be tracked, even if doing so cannot be proven to be reliable<\/a>. Even if one could walk the call stack reliably, you would still<\/i> get it wrong.\n The example I gave originally was the common helper library, where A.DLL<\/code> loads B.DLL<\/code> via an intermediate function in MIDDLE.DLL<\/code>. You want the dependency to be that A.DLL<\/code> depends on B.DLL<\/code>, but instead the dependency gets assigned to MIDDLE.DLL<\/code>.\n “But so what? Instead of a direct dependency from A.DLL<\/code> to B.DLL<\/code>, we just have two dependencies, one from A.DLL<\/code> to MIDDLE.DLL<\/code>, and another from MIDDLE.DLL<\/code> to B.DLL<\/code>. It all comes out to the same thing in the end.”\n Actually, it doesn’t. It comes out much worse.\n After all, MIDDLE.DLL<\/code> is your common helper library. All of the DLLs in your project depend on it. Therefore, the dependency diagram in reality looks like this:<\/p>\n\n\n\n\n
A.DLL<\/code><\/td>\n→<\/td>\nB.DLL<\/code><\/td>\n<\/tr>\n
<\/td>\n↘<\/td>\n↓<\/td>\n<\/tr>\n
<\/td>\nMIDDLE.DLL<\/code><\/td>\n<\/tr>\n<\/table>\n

A.DLL<\/code> depends on B.DLL<\/code>, and both DLLs depend on MIDDLE.DLL<\/code>. That common DLL really should be called BOTTOM.DLL<\/code> since everybody depends on it.\n Now you can see why the dependency chain A.DLL → MIDDLE.DLL → B.DLL<\/code> is horribly wrong. Under the incorrect dependency chain, the DLLs would be uninitialized in the order A.DLL<\/code>, MIDDLE.DLL<\/code>, B.DLL<\/code>, even though B.DLL<\/code> depends on MIDDLE.DLL<\/code>. That’s because your “invented” dependency introduces a cycle in the dependency chain<\/i>, and a bogus one at that. Once you have cycles in the dependency chain, everything falls apart. You took something that might have worked into something that explodes upon impact.\n This situation appears much more often than you think. In fact it happens all the time<\/i>. Because in real life, the loader is implemented in the internal library NTDLL.DLL<\/code>, and KERNEL32.DLL<\/code> is just a wrapper function around the real DLL loader. In other words, if your A.DLL<\/code> calls LoadLibrary(\"B.DLL\")<\/code>, you are already using a middle DLL; its name is KERNEL32.DLL<\/code>. If this “dynamic dependency generation” were followed, then KERNEL32.DLL<\/code> would be listed as dependent on everything<\/i>. When it came time to uninitialize, KERNEL32.DLL<\/code> would uninitialized before all dynamically-loaded DLLs, because it was the one who loaded them, and then all the dynamically-loaded DLLs would find themselves in an interesting world where KERNEL32.DLL<\/code> no longer existed.\n Besides, the original problem arises when A.DLL<\/code> calls a function in B.DLL<\/code> during its DLL_PROCESS_DETACH<\/code> handler, going against the rule that you shouldn’t call anything outside your DLL from your DllMain<\/code> function (except perhaps a little bit of KERNEL32<\/code> but even then, it’s still not the best idea). It’s one thing to make accommodations so that existing bad programs continue to run, but it’s another to build an entire infrastructure built on unreliable heuristics in order to encourage people to do something they shouldn’t be doing in the first place, and whose guesses end up taking a working situation and breaking it.<\/p>\n

You can’t even write programs to take advantage of this new behavior because walking the stack is itself unreliable. You recompile your program with different optimizations, and all of a sudden the stack walking stops working because you enabled tail call elimination. If somebody told you, “Hey, we added this feature that isn’t reliable,” I suspect your reaction would not be “Awesome, let me start depending on it!” <\/p>\n","protected":false},"excerpt":{"rendered":"

Whenever the issue of DLL dependencies arises, I can count on somebody arguing that these dynamic dependencies should be tracked, even if doing so cannot be proven to be reliable. Even if one could walk the call stack reliably, you would still get it wrong. The example I gave originally was the common helper library, […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-17543","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Whenever the issue of DLL dependencies arises, I can count on somebody arguing that these dynamic dependencies should be tracked, even if doing so cannot be proven to be reliable. Even if one could walk the call stack reliably, you would still get it wrong. The example I gave originally was the common helper library, […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/17543","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=17543"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/17543\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=17543"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=17543"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=17543"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}