WinDepends – A Rewrite of the Dependency Walker(github.com)

157 pointsby brataovor 2 Jahren28 comments

WinDepends – A Rewrite of the Dependency Walker

https://github.com/hfiref0x/WinDepends

31 comments

pjmlpvor 2 Jahren

I 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.

forrestthewoodsvor 2 Jahren

> instead of updating to the new Windows ways of dynamic libraries.

What does this mean?

pjmlpvor 2 Jahren

API 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.

emmanueloga_vor 2 Jahren

I suspect there were no career improvement opportunities behind the effort, simple as that.

mistagigglesvor 2 Jahren

There is also this: https://github.com/lucasg/Dependencies Similar project for replacing the old dependency walker tool

blb2vor 2 Jahren

This 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.

HexDecOctBinvor 2 Jahren

I have been using this fork (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.

samivvor 2 Jahren

why not just use the original dependency walker then? It's minimal and if I remember correctly it's all in a self contained executable.

HexDecOctBinvor 2 Jahren

It doesn't work on modern Windows (due to SxS IIRC)

Dweditvor 2 Jahren

It'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.

DonnyVvor 2 Jahren

Its kind of crazy that a person outside of Microsoft is doing this. Why is this not supported by the Sysinternals team?

bhoustonvor 2 Jahren

Nice! I loved and relied on WinDepends back in the day.

secondcomingvor 2 Jahren

Why does a tool such as this need a server?

flopsamjetsamvor 2 Jahren

I 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?

MarekKnapekvor 2 Jahren

There is also this one, but it is no longer maintained. https://github.com/MarekKnapek/DependencyViewer

Dweditvor 2 Jahren

Great! Dependency Walker has been nonfunctional since Windows introduced API sets.

thefourthchimevor 2 Jahren

In the olden times, the internet was so nerdy if you searched on Altavista for "depends" this tool was the top result.

throwaway2037vor 2 Jahren

Is there an equivalent of ldd for Win32?

MatejKafkavor 2 Jahren

`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)}}
  }

dgfitzvor 2 Jahren

This is really neat. Thank you for sharing.

Dweditvor 2 Jahren

There is actual the ldd available on Win32, along with gcc, objdump, etc...

It comes with the mingw or msys suite.

IshKebabvor 2 Jahren

Also is there an equivalent to this for Linux?

sirjazvor 2 Jahren

This is awesome! I hope this doesn't get abandoned.

optimiz3vor 2 Jahren

Nice 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.)

neonsunsetvor 2 Jahren

If you do have headers, you don't have to write the bindings by hand: https://github.com/dotnet/ClangSharp?tab=readme-ov-file#gene...

Also because this is Windows, there is https://github.com/microsoft/CsWin32 already (and adjacent libraries) which rely on the same generator.

pjmlpvor 2 Jahren

Which 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.

[deleted]vor 2 Jahren

exceptionevor 2 Jahren

What do you think about the tooling that @neonsunset mentioned: https://news.ycombinator.com/item?id=42286681

pjmlpvor 2 Jahren

It 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.

[deleted]vor 2 Jahren