| Date: | September 16, 2003 / year-entry #65 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20030916-00/?p=42473 |
| Comments: | 6 |
| Summary: | Because we tried it the other way and it was much worse. In 16-bit Windows, a module that didn't satisfy all its imports would still load. As long as you didn't call a missing import, you were fine. If you did try to call a missing import, you crashed pretty spectacularly with the dreaded Unrecoverable... |
Because we tried it the other way and it was much worse. In 16-bit Windows, a module that didn't satisfy all its imports would still load. As long as you didn't call a missing import, you were fine. If you did try to call a missing import, you crashed pretty spectacularly with the dreaded Unrecoverable Application Error dialog. The Win32 folks decided that this was a bad design, because often people would take Fred App, designed for Windows 3.1, and run it on Windows 3.0, and it would run great for about an hour, at which point Fred App would call a function that was available only in Windows 3.1 (like, say, So the Win32 folks decided that if an import could not be resolved, the app should fail loading. If the makers of Fred App wanted to run on Windows 3.0 after all, they could indicate this by using This issue comes up occasionally when people wish out loud, "Gosh, there should be a way I could mark an import as 'optional' - if it couldn't bind, the load should not fail. It would be the app's responsibility to verify that the bind succeeded before calling it." These people are unwittingly asking for history to repeat itself. |
Comments (6)
Comments are closed. |
A good answer to those asking the question could be "use delay loaded imports" (http://msdn.microsoft.com/library/en-us/vccore/html/vcconlinkersupportfordelayedloadingofdlls.asp)? The programmer must of course still add code for handling loader errors, but the framework for loading the imports on demand is already there, and it’s a smooth one.
You can do this on Linux and MacOS X (iirc) using weak refs. It’s a useful technique, but requires support from the actual libraries you’re linking against (the symbols must be marked as weak). You can check if the symbol is null before calling it.
Typically, dlopen/GetProcAddress is a better way to proceed though, even if it is less convenient.
I’m not saying that it can’t be done. I was trying to explain why allowing it to be done by default was a bad idea. For example, how many people check for a null before using a weak ref or a delayloaded import? Do they even know or care that the function they are calling is weak/delayloaded? Apparently not, because I’ve seen apps crash due to a failed delayloaded import – we’ve reinvented the Windows 3.1 Unrecoverable Application Error dialog.
Of course you did not say anything like it couldn’t be done, and I did not for once think that you did not know about it. However, I thought it would be a good thing letting people know about delay-loaded imports, in case they did not already know.
When it comes to handling loader failures for delay-loaded imports, the linker documentation is very clear stating that your code "must handle errors robustly" and elaborates on how it can be done through exceptions (SEH) or hooks. If used correctly, I even think it’s less error-prone than having a bunch of GetProcAddress-calls scattered throughout your code. After all, many crashes I see on my computers are due to failure of checking return values and dereferencing null pointers. And you wouldn’t use delay-loaded imports indeliberately (using a weak reference is another thing, even another OS).
By the way, I love reading your retrospects on things like the system tr… uhm, notification area. Please keep them coming! :)
I see the point here, but what about a more pressing issue (at least for me):-
Why didn’t CoCreateInstance() load a library using LoadLibraryEx() and not LoadLibrary() … it makes it significantly harder to chain DLL loading in a COM object?
If you forward to a function, it still has to exist.