The "DLL Best Practices" whitepaper is the Microsoft Corporation's original guidance laying out DLL best practices for the Windows platform, namely regarding DllMain.
The document was authored by engineers who were assigned to working on the DLL loader at Microsoft. The final document was published in cooperation with the product manager (PM) who owned the DLL loader (blog announcement #2).
In my opinion, the document was good for its time, except for the main "General Best Practices" section, which throws rules at you without any structure or reasoning. People reading the old DllMain "General Best Practices" today (on Microsoft's documentation website, which has undergone a few updates) tend to come out more confused about DllMain safety than they were going in. So, let's rewrite it with the perspective of an ecosystem where DllMain (module initializer/finalizer or constructor/destructor in the module scope) problems don't happen to begin with. Enter... Unix-like operating systems!
Something worth pointing out is that Old New Thing author Raymond Chen didn't condone referencing his work in the official "DLL Best Practices" whitepaper. Many years have passed since this original statement; however, his extensive Windows experience inside Microsoft makes it nearly impossible not to reference his abundance of work in an educational manner, especially for someone outside of Microsoft who, in the grand scheme of Windows, knows little to nothing about Windows internals like myself (not that anyone could have a firm grasp on the whole of a project that's as large as Windows, but you get what I mean).
Be mindful of the fact that my critiques apply only to the software or company itself and not to the people who contribute to its development. I appreciate and respect the people who put hard work into creating the technologies. Thank you!
Note: This old document states the following about loader lock: "Any function that must read or modify the per-process library-loader data structures must acquire this lock before performing such an operation" (in addition to protecting module initialization/deinitialization). This fact was only true of the legacy Windows loader (e.g. see ReactOS code based on the reverse engineered Windows Server 2003 loader). The modern Windows loader protects library-loader data structures using the LdrpModuleDatatableLock lock. The age of this document also makes it inapplicable to the modern Windows loader in other ways (this amendment is by no means comprehensive).
Current official Microsoft document download | Current official Microsoft document web view | Legacy download page archived