Does anyone know if Microsoft ever published the source code to depends or if there are any samples out there on how to walk the dependency list for a EXE/DLL?
Sam
Printable View
Does anyone know if Microsoft ever published the source code to depends or if there are any samples out there on how to walk the dependency list for a EXE/DLL?
Sam
You could deassembler depends.exe and analyze the ASM code.
Kuphryn
Funny, funny:rolleyes:Quote:
You could deassembler depends.exe and analyze the ASM code.
I'd assume. in step 1 they use the IMAGEHLP Library to find out implicit linkage information and then in step 2 hook LoadLibrary[AW] to recursively apply step (1) on the newly loaded library.
Shoudn't be too difficult - but whoever wants to compete with depends???
Someone that is maintaining and enhancing software that has over 50 DLL's where many of those DLL's are loaded with LoadLibrary. The idea of being able to tell the user (or developer) which exact DLL is missing would be a HUGE time saver, especially when trying to get the debug code set up on the product managers machine! :DQuote:
Originally posted by ReorX but whoever wants to compete with depends???
Take a look at these articles of Matt Pietrek:
Under The Hood
An In-Depth Look into the Win32 Portable Executable File Format
Also you can search in MSDN for "Peering Inside the PE: A Tour of the Win32 Portable Executable File Format".
http://win32assembly.online.fr/pe-tut1.html
may be useful.
Do you need depends.exe or something like that to do this? Why not just a simple standalone app that calls LoadLibrary on all of your DLL's and see which ones fail?Quote:
Originally posted by scarleton
Someone that is maintaining and enhancing software that has over 50 DLL's where many of those DLL's are loaded with LoadLibrary. The idea of being able to tell the user (or developer) which exact DLL is missing would be a HUGE time saver, especially when trying to get the debug code set up on the product managers machine! :D
Regards,
Paul McKenzie
Depends only tells you about implicitly loaded dll's. If you are loading dll's with LoadLibrary(), depends isn't going to help you track down which ones are missing, because it has no way of knowing about them.Quote:
Originally posted by scarleton
Someone that is maintaining and enhancing software that has over 50 DLL's where many of those DLL's are loaded with LoadLibrary. The idea of being able to tell the user (or developer) which exact DLL is missing would be a HUGE time saver, especially when trying to get the debug code set up on the product managers machine! :D
For implicitly loaded dll's the OS will tell you what is missing when you run the program.
Perhaps an initialization function that checks for all the dll's that might get loaded would be good, then you could pop up an error message from within your program.
Or, use an installer to install, even on the lowly product manager's machine. Stop copying files around. :)
Well...no...to find out which dll's are dynamically loaded you need to use the profiling feature of the 'Dependeny Walker'.Quote:
Originally posted by wayside
Depends only tells you about implicitly loaded dll's. If you are loading dll's with LoadLibrary(), depends isn't going to help you track down which ones are missing, because it has no way of knowing about them.
I think the goal is to find out which ones are missing *before* you run the program. Finding out which ones are missing as you demo the software to your boss probably isn't all that helpful. :)Quote:
Originally posted by Andreas Masur
Well...no...to find out which dll's are dynamically loaded you need to use the profiling feature of the 'Dependeny Walker'.
And unless you go through every code path while you run the profiler that is going to load a library, you're not going to know for sure whether all the dll's are really there.
Profiling won't help in a customer support scenario, either, because a customer is unlikely to even have the dependancy walker.
A little tool to verify the environment that your program must run in is a very useful thing to have, and can be used by lots of people in a number of scenarios. I don't think depends is the best tool for the job here.
Well...I agree, however, I do not know any better at the moment... :cool:Quote:
Originally posted by wayside
I don't think depends is the best tool for the job here.
Well... I've been assuming he knows the total set of dlls used by his program, and he's just trying to find out which are missing. Perhaps this is bad assumption. :lol: