Why do DLLs get loaded...
-
...from system32 even if it is copied to the directory the application starts from? I just dealt with a customer over a bug due to this very issue. Two DLLs with the same name were on the system. One DLL was loaded by one application and then the other application loaded the first application's DLL instead of its own. Result? Confusing "ordinal/export not found" messages and the second application refused to start. The Windows loader should be smarter than that. I'd love to hear the rationale behind why Windows can't run a quick check for the DLL in the application's directory BEFORE looking for a cached DLL of the same name elsewhere. Caching systems, by definition, must reflect the equivalent non-cached system 1-to-1. Non-cached DLL search order[^]
-
...from system32 even if it is copied to the directory the application starts from? I just dealt with a customer over a bug due to this very issue. Two DLLs with the same name were on the system. One DLL was loaded by one application and then the other application loaded the first application's DLL instead of its own. Result? Confusing "ordinal/export not found" messages and the second application refused to start. The Windows loader should be smarter than that. I'd love to hear the rationale behind why Windows can't run a quick check for the DLL in the application's directory BEFORE looking for a cached DLL of the same name elsewhere. Caching systems, by definition, must reflect the equivalent non-cached system 1-to-1. Non-cached DLL search order[^]
I suppose that's why MS tacks version numbers on to runtime DLL names :) Sorry for your lost time debugging! Unique DLL names are a good idea :sigh: Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
-
...from system32 even if it is copied to the directory the application starts from? I just dealt with a customer over a bug due to this very issue. Two DLLs with the same name were on the system. One DLL was loaded by one application and then the other application loaded the first application's DLL instead of its own. Result? Confusing "ordinal/export not found" messages and the second application refused to start. The Windows loader should be smarter than that. I'd love to hear the rationale behind why Windows can't run a quick check for the DLL in the application's directory BEFORE looking for a cached DLL of the same name elsewhere. Caching systems, by definition, must reflect the equivalent non-cached system 1-to-1. Non-cached DLL search order[^]
dontknowitall wrote:
I'd love to hear the rationale behind why Windows can't run a quick check for the DLL in the application's directory BEFORE looking for a cached DLL of the same name elsewhere.
Wouldn't that sort of defeat the purpose of cached DLLs? After all, RAM is much faster than the HDD.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
...from system32 even if it is copied to the directory the application starts from? I just dealt with a customer over a bug due to this very issue. Two DLLs with the same name were on the system. One DLL was loaded by one application and then the other application loaded the first application's DLL instead of its own. Result? Confusing "ordinal/export not found" messages and the second application refused to start. The Windows loader should be smarter than that. I'd love to hear the rationale behind why Windows can't run a quick check for the DLL in the application's directory BEFORE looking for a cached DLL of the same name elsewhere. Caching systems, by definition, must reflect the equivalent non-cached system 1-to-1. Non-cached DLL search order[^]
Thank you for posting, I don't knew about that behaviour. On the overall, I agree with you. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
-
dontknowitall wrote:
I'd love to hear the rationale behind why Windows can't run a quick check for the DLL in the application's directory BEFORE looking for a cached DLL of the same name elsewhere.
Wouldn't that sort of defeat the purpose of cached DLLs? After all, RAM is much faster than the HDD.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
DavidCrow wrote:
Wouldn't that sort of defeat the purpose of cached DLLs? After all, RAM is much faster than the HDD.
No - it wouldn't defeat the purpose. The point of caching DLLs is to reduce the amount of RAM used. If two applications happen to have a DLL of the same name and one is running and the other is started, the second application will attempt to use the first application's DLL. Checking for a file's existence in the application's directory before looking at the loaded DLL cache takes almost no time (and could potentially be done in RAM altogether because the file system caches information like that in RAM). A cache, by definition, should return the same exact result as the method used to generate the cached information. To deviate from the definition will cause bugs to appear. Windows does not do this and therefore has "bugs". LoadLibrary() documents this weird behavior but that doesn't make the behavior right/correct.
-
DavidCrow wrote:
Wouldn't that sort of defeat the purpose of cached DLLs? After all, RAM is much faster than the HDD.
No - it wouldn't defeat the purpose. The point of caching DLLs is to reduce the amount of RAM used. If two applications happen to have a DLL of the same name and one is running and the other is started, the second application will attempt to use the first application's DLL. Checking for a file's existence in the application's directory before looking at the loaded DLL cache takes almost no time (and could potentially be done in RAM altogether because the file system caches information like that in RAM). A cache, by definition, should return the same exact result as the method used to generate the cached information. To deviate from the definition will cause bugs to appear. Windows does not do this and therefore has "bugs". LoadLibrary() documents this weird behavior but that doesn't make the behavior right/correct.
It's been this way since the beginning. IMO a part of the whole DLL hell thing. It's one of those backward compatible things that couldn't be changed and we have to live with it. The caching works fine. It is IMO appropriate to look for an already-loaded DLL before going to disk to get it. The problem is, it's done by NAME ONLY. I think it should look at name and VERSION at least. But it doesn't. Complain to Microsoft...good luck ;) Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
