winfile 1.1.5

Fix glob expansion on Windows — winfile *.ext now works correctly from cmd.exe and PowerShell.

winfile 1.1.4

A cosmetic release. Detection is unchanged from 1.1.0 — see those notes for the
ELF work.

--version now separates the program name from the version with a space,
matching every other tool in the win* suite:

winfile v1.1.4      (was: winfile-v1.1.3)

Binaries

Asset	Platform
winfile_windows_amd64.exe	Windows, x86-64
winfile_windows_arm64.exe	Windows, ARM64
winfile_linux_amd64	Linux, x86-64
winfile_linux_arm64	Linux, ARM64

Each is self-contained: put one on your PATH and run it, nothing to extract or
install. On Linux, chmod +x it first. The binary takes its name from
argv[0], so a renamed copy reports its own name.

Re-verified against GNU file 5.41 over the same 1348-file corpus before
publishing: no differences in the description, --mime-type, -i or
--extension.

winfile 1.1.3

A maintenance release. Detection is unchanged from 1.1.0 — see those notes for
the ELF work.

winfile --version now reports the real version however you installed it:

go install github.com/fermat-tech/winfile@latest   ->  winfile-v1.1.3

git clone https://github.com/fermat-tech/winfile
cd winfile
go build -trimpath -o winfile.exe .                ->  winfile-v1.1.3

1.1.1 moved the version to a build-time flag, which meant these two routes
reported dev — neither passes that flag. The version now falls back to the
module version the Go toolchain embeds in the binary, so building from source
needs no special incantation. Release binaries still pin the version
explicitly.

Binaries

Asset	Platform
winfile_windows_amd64.exe	Windows, x86-64
winfile_windows_arm64.exe	Windows, ARM64
winfile_linux_amd64	Linux, x86-64
winfile_linux_arm64	Linux, ARM64

Each is self-contained: put one on your PATH and run it, nothing to extract or
install. On Linux, chmod +x it first. The binary takes its name from
argv[0], so a renamed copy reports its own name.

Re-verified against GNU file 5.41 over the same 1348-file corpus before
publishing: no differences in the description, --mime-type, -i or
--extension.

winfile 1.1.1

A maintenance release. Detection is unchanged from 1.1.0 — see those notes for
the ELF work.

winfile hardcoded its version in the source, which meant the release build
could not stamp the tag into the binary and a forgotten bump would have shipped
a stale version string with nothing to catch it. The version is now supplied at
build time, matching every other tool in the win* suite:

• Release binaries are built with -ldflags "-X main.version=vX.Y.Z" and report
  the tag they were cut from.
• A plain go build from source reports dev, rather than claiming to be a
  release it is not.

--version still takes the program name from argv[0], so a renamed copy
reports its own name.

Binaries

Asset	Platform
winfile_windows_amd64.exe	Windows, x86-64
winfile_windows_arm64.exe	Windows, ARM64
winfile_linux_amd64	Linux, x86-64
winfile_linux_arm64	Linux, ARM64

Each is self-contained: put one on your PATH and run it, nothing to extract or
install. On Linux, chmod +x it first.

Re-verified against GNU file 5.41 over the same 1348-file corpus before
publishing: no differences in the description, --mime-type, -i or
--extension.

winfile 1.1.0

This release closes the gap named at the bottom of the 1.0.0 notes: ELF binaries
were reported only by their broad class. They are now described the way GNU
file describes them.

1.0.0:  ELF 64-bit LSB shared object

1.1.0:  ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked,
        interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc6a4214…,
        for GNU/Linux 3.2.0, stripped

Core dumps report where they came from:

ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from '/usr/bin/crasher',
real uid: 1000, effective uid: 1000, real gid: 1000, effective gid: 1000,
execfn: '/usr/bin/crasher', platform: 'x86_64'

What is reported

Object type, machine, ELF version and OS/ABI; linkage (dynamically,
statically or static-pie linked); the PT_INTERP interpreter path; GNU and
Go build IDs; the .note.ABI-tag target OS and version; presence of
.debug_info; stripped state; and, for core dumps, the dumping process with its
real and effective uid and gid, execfn and platform.

Two of these are inferred rather than read from a field, matching what GNU file
does. An ET_DYN image is a pie executable when its .dynamic section
carries DT_FLAGS_1 with DF_1_PIE, and a shared library otherwise. It is
static-pie linked when it has no interpreter and no DT_NEEDED entries, so
there is nothing to bind at run time.

MIME output follows suit — -i and --mime-type now distinguish
application/x-executable, x-pie-executable, x-sharedlib, x-object and
x-coredump instead of reporting a single type for every ELF file.
--extension reports ???, as GNU file does for ELF.

Verified against the original

Differentially tested against GNU file 5.41 over a 1348-file corpus — /bin,
shared libraries, relocatable objects, static and PIE executables, Go binaries
and a real core dump — with no differences in the description, --mime-type,
-i or --extension.

Known differences are listed in the README. The main one: only x86-64, i386, ARM,
AArch64, RISC-V and 64-bit PowerPC are named. The e_machine table has a long
tail, and winfile leaves an unrecognised machine unnamed rather than guessing at
it.

Binaries

Asset	Platform
winfile_windows_amd64.exe	Windows, x86-64
winfile_windows_arm64.exe	Windows, ARM64
winfile_linux_amd64	Linux, x86-64
winfile_linux_arm64	Linux, ARM64

Each is self-contained: put one on your PATH and run it, nothing to extract or
install. On Linux, chmod +x it first.

The binary takes its name from argv[0], so renaming it renames the tool in its
own messages — copy it as winfile.exe, or as file if you would rather it
answered to that.

winfile 1.0.0

A port of the Unix file command for Windows and Linux. It identifies what a
file is by looking inside it — magic-byte signatures, structural markers, and
encoding heuristics — rather than trusting the extension, which is a convention a
file may or may not honour. Output follows GNU file, so it drops into existing
scripts and pipelines unchanged.

Windows ships nothing equivalent.

Binaries

Asset	Platform
winfile_windows_amd64.exe	Windows, x86-64
winfile_windows_arm64.exe	Windows, ARM64
winfile_linux_amd64	Linux, x86-64
winfile_linux_arm64	Linux, ARM64

Each is self-contained: put one on your PATH and run it, nothing to extract or
install. On Linux, chmod +x it first.

The binary takes its name from argv[0], so renaming it renames the tool in its
own messages — copy it as winfile.exe, or as file if you would rather it
answered to that.

What it detects

Images, audio and video containers, archives (ZIP, gzip, bzip2, XZ, zstd, LZ4,
7-Zip, RAR, tar, cab, ar), OOXML documents and other ZIP-based containers such as
EPUB, JAR and APK, executables and object files for several platforms, databases,
fonts, and a text pass that reports the encoding — ASCII, UTF-8, UTF-16 with
either byte order, and Latin-1 — along with the line endings.

Verified against the original

Checked against GNU file on Linux, which agrees on PDFs, ASCII text and the
other everyday cases. One known gap: for ELF binaries winfile reports the
broad class — ELF 64-bit LSB shared object — where GNU file goes on to name
the architecture, interpreter, build ID and stripped state.