[HN Gopher] WinDepends - A Rewrite of the Dependency Walker
___________________________________________________________________
WinDepends - A Rewrite of the Dependency Walker
Author : bratao
Score : 146 points
Date : 2024-11-23 12:48 UTC (8 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Dwedit wrote:
| Great! Dependency Walker has been nonfunctional since Windows
| introduced API sets.
| mistagiggles wrote:
| There is also this: https://github.com/lucasg/Dependencies
| Similar project for replacing the old dependency walker tool
| blb2 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| It doesn't work on modern Windows (due to SxS IIRC)
| Dwedit wrote:
| 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.
| sirjaz wrote:
| This is awesome! I hope this doesn't get abandoned.
| pjmlp wrote:
| 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_ wrote:
| I suspect there were no career improvement opportunities behind
| the effort, simple as that.
| forrestthewoods wrote:
| > instead of updating to the new Windows ways of dynamic
| libraries.
|
| What does this mean?
| bhouston wrote:
| Nice! I loved and relied on WinDepends back in the day.
| optimiz3 wrote:
| 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.)
| neonsunset wrote:
| 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.
| pjmlp wrote:
| 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.
| exceptione wrote:
| What do you think about the tooling that @neonsunset
| mentioned: https://news.ycombinator.com/item?id=42286681
| pjmlp wrote:
| 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.
| throwaway2037 wrote:
| Is there an equivalent of ldd for Win32?
| MatejKafka wrote:
| `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 wrote:
| This is really neat. Thank you for sharing.
| Dwedit wrote:
| There is actual the ldd available on Win32, along with gcc,
| objdump, etc...
|
| It comes with the mingw or msys suite.
| IshKebab wrote:
| Also is there an equivalent to this for Linux?
| secondcoming wrote:
| Why does a tool such as this need a server?
| flopsamjetsam wrote:
| 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?
| thefourthchime wrote:
| In the olden times, the internet was so nerdy if you searched on
| Altavista for "depends" this tool was the top result.
| MarekKnapek wrote:
| There is also this one, but it is no longer maintained.
| https://github.com/MarekKnapek/DependencyViewer
| DonnyV wrote:
| Its kind of crazy that a person outside of Microsoft is doing
| this. Why is this not supported by the Sysinternals team?
___________________________________________________________________
(page generated 2024-12-01 23:01 UTC)