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.

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

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

What does this mean?

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.

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

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.

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.

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.

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

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.

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

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

Why does a tool such as this need a server?

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?

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

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

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

Is there an equivalent of ldd for Win32?

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

This is really neat. Thank you for sharing.

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

It comes with the mingw or msys suite.

Also is there an equivalent to this for Linux?

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

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

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.

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.

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

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.