WinDepends – A Rewrite of the Dependency Walker

157 pointsposted a year ago
by bratao

31 Comments

pjmlp

a year ago

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.

emmanueloga_

a year ago

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

forrestthewoods

a year ago

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

What does this mean?

pjmlp

a year ago

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.

mistagiggles

a year ago

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

blb2

a year ago

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.

HexDecOctBin

a year ago

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.

samiv

a year ago

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.

HexDecOctBin

a year ago

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

Dwedit

a year ago

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.

DonnyV

a year ago

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

bhouston

a year ago

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

secondcoming

a year ago

Why does a tool such as this need a server?

flopsamjetsam

a year ago

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?

Dwedit

a year ago

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

thefourthchime

a year ago

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

throwaway2037

a year ago

Is there an equivalent of ldd for Win32?

MatejKafka

a year 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

a year ago

This is really neat. Thank you for sharing.

Dwedit

a year ago

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

It comes with the mingw or msys suite.

IshKebab

a year ago

Also is there an equivalent to this for Linux?

sirjaz

a year ago

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

optimiz3

a year ago

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

pjmlp

a year ago

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.

user

a year ago

[deleted]

exceptione

a year ago

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

pjmlp

a year ago

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.

user

a year ago

[deleted]

user

a year ago

[deleted]