Elliot Killick
8f9257c1da
From June to now, most of my time on this project was spent writing "The Rise of Microsoft". Researching and writing that thing took an inordinate amount of time. Also, I took a break to work primarily on another unreleased project I have before switching back to this one. I am proud of what I got here though and I feel like it is all coming together. My plans for the whitepapers are already well drafted and I know they will make an impact. I have learned a ton from working on this project and it has definitely given me something to idly think about and work on in my spare time. Finishing "The Problem with How Windows Uses Threads" was something I thought I wanted done before this release, but oh well. The main README is at about 50K words now, plus all the other smaller documents and you are looking at about a small novel's worth of technical writing. And technical writing takes multiple times longer than typical story writing. Anyway, this project is exciting for me - people who I show it to also really like it - and I am even more excited about what is to come!
Library Initializer Lazy Loading Experiment
Microsoft documentation states this in regard to delay loading and DllMain:
A DLL project that delays the loading of one or more DLLs itself shouldn't call a delay-loaded entry point in
DllMain.
Microsoft's reasoning for this statement is likely that Windows and possibly other subsystems often use delay loading as a hack for postponing when a circular dependency is loaded. In practice, the stated target is unachievable because executing code cannot know whether calling an import in another DLL will trigger a delay load somewhere in the dependency chain. The only resolution then is to either do nothing from DllMain, or axe delay loading and break dependency cycles.
Find instances of delay loading in a call stack by looking for the function: __delayLoadHelper2