[FEATURE REQUEST] peports: detect arch

[avih]

I know there are/were plans to extend peports to test deps recursively, however, this can also be done in a sh script, relatively trivially (and assuming the lookup procedure is well documented).

What cannot be done trivially in sh, however, is to ensure that the detected deps match the arch of original file, and this is cricial while walking the deps, as mismatching arch of the dep should abort this dep. Maybe it should keep looking for this dep elsewhere in PATH, but I'm not very familiar with windows dll lookup procedure.

So I request a feature: some option to print the arch of a binary (and nothing else), so that a script could capture the arch of the original file, and compare it to the arch of dependencies it identifies as potential matches.

I don't know how the arch is encoded at the binary, buf if it's not "x86_64", "i386", etc, then there's a question of whether or not to print it more human-friendly, like the strings above. I don't think that's required, but even if it is implemented, then it should still be possible to use it with an unknown arch value of the binary (a number or however else the arch is stored at the binary), so that it's still usable with unknown archs.

Thanks.

[Peter0x44]

That's a great idea. This is one of my primary use cases of file (to find out the arch/format of an object file or dll/executable).

I'll see what I can do about it. I don't think it's that difficult.

It is just a field in the IMAGE_FILE_HEADER.
https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_file_header

https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#machine-types

Here's a list of all the supported machine types windows has for the pe. Probably only "i386" (hate this name), x86_64, aarch64 are really relevant. But there's no reason not to enumerate them all.

[avih]

Yes. file is indeed one solution which I did consider, and while it should be sufficient for this task, and I did compile it for windows/mingw, it's not trivial to compile it, its output is not strictly intended for parsing, it does a lot more things than necessary here, and it's also not readily available out there (maybe except msys2 /cygwin).

[Peter0x44]

What cannot be done trivially in sh, however, is to ensure that the detected deps match the arch of original file, and this is cricial while walking the deps, as mismatching arch of the dep should abort this dep.

Actually, there is one exception to this. It is "ARM64EC". Which is a very strange microsoft solution to porting applications to arm, basically you can call x64 code from ARM64EC and it works fine. Currently, this is only supported by MSVC.

[Peter0x44]

I did compile it for windows/mingw

If you did it with w64devkit, please add it to contrib! I would totally use this.

[avih]

I did compile it for windows/mingw

If you did it with w64devkit, please add it to contrib! I would totally use this.

IIRC I did build it with w64dk, but I don't think it belongs in contrib. It's a well-established 3rd party package, consisting of many files.

If you want the binary or the build procedure, it's here:

file-mingw-x32-x64--2025-06-05--avih-build.zip

[Peter0x44]

I have implemented this in #271 . Is this what you're after?

[Peter0x44]

I don't speak for @skeeto , but there is existing precedent to have build scripts with dependencies that aren't included in contrib.
I think the libregex.c for example expects you to supply your own PCRE. This is perfect usecase for contrib.

[avih]

there is existing precedent to have build scripts or dependencies that aren't included in contrib.

I know. I still don't think it belongs there. Feel free to follow the README in the zip and open a PR with such script.

[Peter0x44]

If machine parsing is the objective, maybe -j for emitting a json could be a good feature. But it might also be unneeded.

[avih]

I have implemented this in #271 . Is this what you're after?

Some comments, though it's not for me to decide:

I think it's OK (didn't test). Getting the raw value seems trivial, which is nice.

I'd drop the "title" (MACHINE TYPE), because the docs says what it prints.

Maybe document the output format (at the -h output) to make it formally parsable (e.g. as printf("%s (0x%04x)\n", NAME, CODE);), or maybe the other way around (0x... (NAME)) so that the raw value is easier to extract (up to first space).

According to the source-comment, for value of 0x0 it should probably print "ANY" rather than "UNKNOWN", and for other values (which currently print "UNKNOWN"), "OTHER" might be viable too.

FWIW, I think it's probably enough to print only the hex value, and document the values of i386/x64/aarch64 at the -h output, instead of this bigass names table.

Thanks.

[avih]

If machine parsing is the objective, maybe -j for emitting a json could be a good feature. But it might also be unneeded.

It is the objective of my request, but it only prints a single value, so I don't think JSON is needed here, as it only makes the output processing less simple.

[Peter0x44]

According to the source-comment, for value of 0x0 it should probably print "ANY" rather than "UNKNOWN", and for other values (which currently print "UNKNOWN"), "OTHER" might be viable too.

That is just how microsoft documents it. From their table:

Constant	Value	Description
IMAGE_FILE_MACHINE_UNKNOWN	0x0	The content of this field is assumed to be applicable to any machine type

I suppose I could use other to distinguish something nonzero and also not in the table. But I expect probably no one will ever even hit that.

[skeeto]

I did build it with w64dk

Interesting, thanks for sharing! I agree that it's bit more complicated for the sorts of scripts I have contrib/, particularly because it involves two dependencies in tow. That's enough to be its own repository. For example, my f2c fork is too much for contrib/.