6 ms·
WinDepends – A Rewrite of the Dependency Walker
- Dwedit 2y agoGreat! Dependency Walker has been nonfunctional since Windows introduced API sets.
- mistagiggles 2y agoThere is also this: https://github.com/lucasg/Dependencies https://github.com/lucasg/Dependencies Similar project for replacing the old dependency walker tool
- blb2 2y agoThis is the one I've been using and it's decent. I'm just worried that there hasn't been much activity in the repo and fear it's abandoned.
- HexDecOctBin 2y agoI have been using this fork (https://github.com/lhak/Dependencies https://github.com/lhak/Dependencies). But I hate how this software comes with dozens of DLLs. I like to chuck these tools in sa single directory, and this is one that I have to put in a separate folder. DependencyWalker was better in this regard.
- samiv 2y agowhy not just use the original dependency walker then? It's minimal and if I remember correctly it's all in a self contained executable.
- HexDecOctBin 2y agoIt doesn't work on modern Windows (due to SxS IIRC)
- Dwedit 2y agoIt's API sets that broke it, not SxS. You see these as the program trying to import nonexistent DLL files that start with the name "api-ms-win-". Dependency Walker can't handle those imports at all, it only deals with real DLL files.
- sirjaz 2y agoThis is awesome! I hope this doesn't get abandoned.
- pjmlp 2y agoI never understood why those responsible for Windows SDK dropped Dependency Walker, instead of updating to the new Windows ways of dynamic libraries. Most certainly they keep having similar tooling in Redmond.
- emmanueloga_ 2y agoI suspect there were no career improvement opportunities behind the effort, simple as that.
- forrestthewoods 2y ago> instead of updating to the new Windows ways of dynamic libraries. What does this mean?
- pjmlp 2y agoAPI Sets, SxS manifests, Visual C++ linker delay loading, .NET Assembly loading and related fusion cache, UWP sandbox loading, are some examples of changes the original dependency walker isn't capable to handle.
- bhouston 2y agoNice! I loved and relied on WinDepends back in the day.
- optimiz3 2y agoNice project, just as a challenge / piece of feedback - most of the time you don't actually need to have a C backend for this type of project. The challenge is to get all the P/Invoke signatures and struct declarations / pointer walking correct on .Net. The benefit being a single managed EXE and no need for cross process communication and the edge cases it brings. (Source: Have built a full SCSI interop layer in .Net to do low level CD ripping, full with native pointer walking and all. Have also written tools to walk the PEB (process environment block) in .Net w/ no native backends.)
- neonsunset 2y agoIf you do have headers, you don't have to write the bindings by hand: https://github.com/dotnet/ClangSharp?tab=readme-ov-file#generating-bindings https://github.com/dotnet/ClangSharp?tab=readme-ov-file#gene... Also because this is Windows, there is https://github.com/microsoft/CsWin32 https://github.com/microsoft/CsWin32 already (and adjacent libraries) which rely on the same generator.
- pjmlp 2y agoWhich is the reason that to this day I remain a big C++/CLI fan. It is still much easier than dealing with P/Invoke and COM from .NET code. Create a nice wrapper, exposing C# compatible types and we're done. In regards to COM, not even the CCW/RCW replacement is as developer friendly as VB 6 or Delphi. I have some hopes that Secure Future Initiative will finally give the spotlight to .NET on Windows, that Windows team keeps pushing away, unlike what happens on Apple and Google platforms.
- exceptione 2y agoWhat do you think about the tooling that @neonsunset mentioned: https://news.ycombinator.com/item?id=42286681 https://news.ycombinator.com/item?id=42286681
- pjmlp 2y agoIt helps, but when one has enough C++ knowledge, I still consider C++/CLI a better solution instead of yet another tool, that might not understand everything. Now if doing cross platform code, C++/CLI is naturally not an option.
- throwaway2037 2y agoIs there an equivalent of ldd for Win32?
- MatejKafka 2y ago`dumpbin /dependents` gives similar information. I use the following PowerShell function to get output that's a bit closer to ldd: function ldd($ExePath) { $Dumpbin = gi "C:\Program Files*\Microsoft Visual Studio\*\*\VC\Tools\MSVC\*\bin\HostX64\x64\dumpbin.exe" $Done = $false & $Dumpbin /dependents $ExePath | ? {$_.StartsWith(" ")} | % {$_.Substring(2)} | % {if ($Done) {} elseif ($_ -eq "Summary") {$Done = $true} else {$_}} | % {if ($_.StartsWith(" ")) {$_.Substring(2)}} }
- dgfitz 2y agoThis is really neat. Thank you for sharing.
- Dwedit 2y agoThere is actual the ldd available on Win32, along with gcc, objdump, etc... It comes with the mingw or msys suite.
- IshKebab 2y agoAlso is there an equivalent to this for Linux?
- secondcoming 2y agoWhy does a tool such as this need a server?
- flopsamjetsam 2y agoI thought at first it was a way to share the symbol tables between multiple instances (though you could use memory mapping), but then I read this in the README.md: > Server is written in C, with no special headers or SDK used. So maybe it helps them keep the parser simpler? Decouples that part from the GUI in a way they prefer?
- thefourthchime 2y agoIn the olden times, the internet was so nerdy if you searched on Altavista for "depends" this tool was the top result.
- MarekKnapek 2y agoThere is also this one, but it is no longer maintained. https://github.com/MarekKnapek/DependencyViewer https://github.com/MarekKnapek/DependencyViewer
- DonnyV 2y agoIts kind of crazy that a person outside of Microsoft is doing this. Why is this not supported by the Sysinternals team?