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

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.

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

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.

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

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.

The big conflict between .NET and windows is because the windows team correctly understood that if you give people a way to use their programs without the rest of the windows interface then they will do that and question why they really need Windows at all. Windows 8 was about giving people more Windows in their Windows with an attempt to push more functionality away from programs and into the operating system - it was a total disaster. Microsoft internally had a managed OS called Midori which worked great. But we can’t have nice things because the people who have a monopoly wish to maintain that monopoly, so while replacing more of OS functionality with dotnet makes perfect sense I think it’s unlikely to happen for this reason.

I’ve been out of Microsoft for a while and don’t really pay much attention anymore but I heard a rumor that the Windows team was moved under Azure. This would be a weird twist of fate since it was Windows that forced Scott Gu to kill Silverlight, a dotnet in the browser. The browser in effect being a competing OS.

I asked a windows designer why they did something stupid and their response was the design change was in order to be familiar to people who are unfamiliar with Windows, they’re focused on growth and they want to bring in mobile and apple users. I tried to describe how stupid that was since Microsoft is already a zoo of all previous Microsoft design philosophies and now they are introducing addition 3rd party designs into that mix. Understandably the people who make such dumb decisions in the first place are incapable of understanding why it is a dumb decision.

In my view the future of dotnet is on Linux, I sell software to old lagging organizations, and for them the push into the browser was about getting away from windows, effectively treating the browser as an OS.

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?

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?

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

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

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