I miss the command `ldd` of Cygwin/MSYS2

I used this command in Linux/FreeBSD. I was very surprise that it's available on Cygwin/MSYS2 and it's working very well indeed. I expected it's just a stub and will not do anything useful on Windows. It turned out that I was wrong. I use it as the replacement for the deprecated Dependency Walker and the new bloated Dependencies tool written in .NET.

@brechtsanders' pedeps utility looks cool. But I still think ldd is easier to use.

[brechtsanders]

@brechtsanders' pedeps utility looks cool. But I still think ldd is easier to use.

That's fine. The primary goal of pedeps was to have a library for looking into .exe and .dll files.

[skeeto]

I never found a native ldd implementation for Windows, just Cygwin/MSYS2. Otherwise, if it was of suitable quality I would have included it already. The last couple w64dk releases have a new command, peports, for listing import and export tables. In its roadmap (see the src/peports.c header) I listed a possible recursive mode that searches PATH for imported modules and keeps going, which if implemented would be like ldd.

[brechtsanders]

What about the one at https://github.com/Sharp0802/lddw ?

[skeeto]

Thanks, @brechtsanders! I hadn't come across lddw, and it's essentially what I said I wanted (native ldd). I recognize that you're not endorsing it, but being helpful after you were summoned, which I greatly appreciate. From an evaluation standpoint, I'm not entirely happy with what I see, and I wouldn't consider including it without a significant overhaul, which is perhaps worth the effort. At the very least its Windows-unique option to exclude API sets is a good idea worth copying. Since it's archived I'd need to fork the project anyway. Documenting my review for the future: * It was written in 2023 but uses 1993-era, 16-bit string conventions (TCHAR), and yet still too inconsistently to get the "benefits" of it. * It's full of buffer overflows and crashes on just about any invalid input that passes the initial magic checks. The README's "You can use lddw on an untrusted executable" is true in the dynamic linker sense, but not in the trusted input sense. The use of the "secure string" _s functions may have silently truncated instead of overflowing but, as usual, they're used incorrectly. * Its Mingw-w64-only status will work for w64dk, but makes it difficult to evaluate. Porting to MSVC so I could use ASan was simple, but porting at least the core to Linux so I could fuzz test (to shake out as many bugs as I can) would take a near rewrite. * It's confused about encodings. Module names are by definition ASCII and should not be decoded as UTF-8 for use in the wide API. If non-ASCII bytes are found, if anything they should be decoded using the active code page. (Side note: As an interesting consequence, on Windows changing the active code page may change which DLL is loaded.) * It uses a CRT without initializing it. That's corrected just by using a proper entry point. From build.ps1 it looks like a hack to use UCRT with a MSVCRT toolchain. That's fine for toy programs, but I wouldn't distribute binaries built that way. On x86 it also doesn't align the stack properly: more a GCC bug, but must still be mitigated. * Nitpicky and subtle, and mainly Microsoft's fault for documenting this so poorly, but I want to note it while it's in mind: the locale-dependent wcsnicmp is inappropriate for case-insensitive file name comparisons. My tolerance for bugs is balanced against the usefulness of a tool. I tolerate lots of GDB bugs because there's no other option. A dependency walker is doing relatively little work, for a niche purpose, so I'm pickier about it.

@brechtsanders' pedeps utility looks cool. But I still think ldd is easier to use.

That's fine. The primary goal of pedeps was to have a library for looking into .exe and .dll files.

@skeeto pedeps is not only a library, it also has an utility named listpedeps that doing pretty much what ldd does. You can skip the libavl dependency if you don't build the copypedeps utility.

It seems listpedeps can't handle dependencies of a dependency properly. ldd can list every dynamic libraries required for the program to run. I don't care about if it actually tries to execute the program to get the list of dependencies or not. This is what the ldd utility on Unix does and I don't think it's a problem.

[brechtsanders]

If a specific added feature would be nice to have in listpedeps don't hesitate to describe the wanted feature in a ticket at https://github.com/brechtsanders/pedeps/issues

If a specific added feature would be nice to have in listpedeps don't hesitate to describe the wanted feature in a ticket at https://github.com/brechtsanders/pedeps/issues

Is it possible to tell listpedeps to not include IMPORTS (or EXPORTS) in its output?

[brechtsanders]

Do you mean you want command options to only get output like this?

architecture: x86_64
machine name: AMD AMD64 (x64)
subsystem:    Windows console
DLL:          no
stripped:     yes
file version: 0.0
minimum Windows version: 5.2

Do you mean you want command options to only get output like this?

architecture: x86_64
machine name: AMD AMD64 (x64)
subsystem:    Windows console
DLL:          no
stripped:     yes
file version: 0.0
minimum Windows version: 5.2

I consider this to be the standard information about the binary. But I don't want to view both IMPORTS and EXPORTS at the same time. There should be option switches to display only IMPORTS (e.g: -i?) or EXPORTS (e.g: -e?).

listpedeps doesn't accept the -h switch? I want to view help.