If dynamic DLL dependencies were tracked, they'd be all backwards

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Alexandre Grigoriev — Fri, 10 Jul 2009 17:21:01 GMT

I don't get your point about KERNEL32.DLL. It doesn't need to uninitialize anything in PROCESS_DETACH. You can't unload it. When it's time for it to go, the process is on the way down.

[You're getting too caught up in implementation details and missing the point of the article. -Raymond]

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Tom — Fri, 10 Jul 2009 17:23:01 GMT

Editorial note: The sentence fragment 'even if doing so is cannot be proven to be reliable.' has a superfluous 'is' and should be 'even if doing so cannot be proven to be reliable.'.

[Fixed. Thanks. -Raymond]

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Mark (The other Mark) — Fri, 10 Jul 2009 17:44:26 GMT

"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!""

My reaction might not be, but I suspect many people would say exactly that. Check out Raymond Chen's blog, especially the parts about compatibility shims, or people depending on undocumented implementation details... :-)

Note: The Smiley indicates this is intended to be a "funny" comment, as many entries in your blog point out that yes, people are silly enough to depend on unreliable behavior.

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Someone You Know — Fri, 10 Jul 2009 17:57:16 GMT

"...all the dynamically-loaded DLLs would find themselves in an interesting world where KERNEL32.DLL no longer existed."

This reminds me of that supposedly ancient curse that goes: "May you live in interesting times."

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Peter Bindels — Fri, 10 Jul 2009 23:16:48 GMT

This is exactly why there is no definite implementation of a singleton in C++ (or any other language for that matter) - you have the same kind of fake dependencies, where the order of destruction is wrong no matter how you construct them.

re: If dynamic DLL dependencies were tracked, they'd be all backwards

porter — Fri, 10 Jul 2009 23:55:17 GMT

>> shouldn't call anything outside your DLL from your DllMain function (except perhaps a little bit of KERNEL32 but even then, it's still not the best idea).

What about initializing my DLL's global critical section?

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Anonymous Coward — Sat, 11 Jul 2009 02:22:40 GMT

>What about initializing my DLL's global critical section?

It is safe to call other functions in Kernel32.dll, because this DLL is guaranteed to be loaded in the process address space when the entry-point function is called. It is common for the entry-point function to create synchronization objects such as critical sections and mutexes, and use TLS. Do not call the registry functions, because they are located in Advapi32.dll. If you are dynamically linking with the C run-time library, do not call malloc; instead, call HeapAlloc.

-the Platform SDK

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Doug — Sat, 11 Jul 2009 05:07:32 GMT

What I find amusing, having been down the Dllmain path many times, from the MSDN reading developer perspective, is the number of rules that are either not written or described in a cryptic manner.

It wouldn't have been so bad, except that Visual Basic liked to unload DLLs at times other than process death, meaning you HAD to make sure your threads were stopped. No matter what they were doing. Getting that to work correctly is not a simple task.

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Karellen — Sat, 11 Jul 2009 17:37:59 GMT

"A.DLL loads B.DLL [...] You want the dependency to be that A.DLL depends on B.DLL"

And that's where things have gotten backwards.

If RANDOM.DLL depends on CORE.DLL (e.g. kernel32.dll), then CORE.DLL must be loaded and intialised *before* RANDOM.DLL, and CORE.DLL must be around until after RANDOM.DLL has been released/unloaded.

If RANDOM.DLL dynamically loads MODULE.DLL, then it follows that RANDOM.DLL must have been loaded, initialised and running before MODULE.DLL. It is therefore inherently erroneous to say that RANDOM.DLL "depends on" MODULE.DLL. If anything, you'd want to introduce a fake dependency saying that the dynamically loaded MODULE.DLL depends on RANDOM.DLL.

That way, if RANDOM.DLL starts to go away, you'd want to unload MODULE.DLL *first*, releasing your resources in the opposite order to that which they were acquired. However, that cannot work in the general case because it's possible in the semantics of that application for RANDOM.DLL to have "transferred ownership/cleanup responsibility" of MODULE.DLL to CORE.DLL, and CORE.DLL might still be using MODULE.DLL.

[And if we followed your rules, then all delay-loads would have backwards dependencies. FANCY.DLL uses WININET.DLL only in certain scenarios, so instead of declaring a load-time dependency, it loads WININET.DLL on demand. According to your logic, this means that WININET.DLL depends on FANCY.DLL and therefore WININET.DLL should be shut down before FANCY.DLL. When FANCY.DLL calls InternetCloseHandle() in its DLL_PROCESS_DETACH, it ends up calling into a DLL that has already been uninitialized. -Raymond]

re: If dynamic DLL dependencies were tracked, they'd be all backwards

John — Sun, 12 Jul 2009 02:04:08 GMT

>When FANCY.DLL calls InternetCloseHandle() in its DLL_PROCESS_DETACH, it ends up calling into a DLL that has already been uninitialized.

Good! Serves the bastards right for breaking the DllMain contract. But I guess Microsoft wouldn't know anything about that. Do you guys enjoy being slaves to design/compatibility decisions made 25+ years ago? I bet there is an alternate dimension where Windows 7 only allows 8.3 filenames.

[You missed the underlying counterfactual, which was "If Windows tracked DLL dependencies better, then we wouldn't need these crazy rules about DLL_PROCESS_DETACH." Your argument is therefore circular: "Changing the rules by tracking dependencies better is a bad idea because that would make it possible to change the rules!" -Raymond]

re: If dynamic DLL dependencies were tracked, they'd be all backwards

porter — Sun, 12 Jul 2009 04:18:22 GMT

>> It wouldn't have been so bad, except that Visual Basic liked to unload DLLs at times other than process death, meaning you HAD to make sure your threads were stopped.

32bit OS/2 required all threads to terminate before a process ended.

re: If dynamic DLL dependencies were tracked, they'd be all backwards

John — Sun, 12 Jul 2009 06:25:07 GMT

I understand that, but my comment wasn't specifically aimed at this topic; it was more about (breaking) backward compatibility in general.

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Aaron Margosis — Sun, 12 Jul 2009 08:08:58 GMT

@John - yes, compatibility is a bitch. But throwing away compatibility hurts customers (which hurts business). So you just acknowledge it and deal with it.

It's hardly unique to Microsoft, though, or to the software industry. Look around and you'll see all kinds of decisions based on backward compatibility. E.g., "cigarette lighter" jacks in (American) cars becoming the standard form factor for power outlets.

re: If dynamic DLL dependencies were tracked, they'd be all backwards

bahbar — Mon, 13 Jul 2009 15:45:01 GMT

@Aaron,

Actually, those jacks are probably one of the best followed de facto standards throughout the world. Try and plug a US standard power plug in Europe, and then try your car-jack plug. Guess which one works...

re: If dynamic DLL dependencies were tracked, they'd be all backwards

Aaron Margosis — Mon, 13 Jul 2009 18:16:49 GMT

@bahbar - I didn't want to assume that what's true in the US is true around the world, but I'm not surprised that this one is. The point is, though, that if you were designing a standard form factor for a power outlet, would your first idea be something that you could easily stick large fingers or thumbs into? Oh - and the English language itself. It's a total mess, but it's what we've got.