Binary files
Sizes, a SHA-256 of each side, and a verdict. Identical or different, and nothing beyond that — because for two opaque files, nothing beyond that is honest.
The verdict#
Two binaries produce one card. Not a diff: a determination, with the evidence that produced it.
| Row | What it shows |
|---|---|
| Verdict | Identical or different, with a one-line reason — the same bytes, the same size but different hashes, or how much the after side grew or shrank |
| Name | Both file names |
| Size | Both sizes |
| SHA-256 | Both hashes, or not needed where the answer was already settled |
A size difference is conclusive on its own, so hashing only runs when the two sizes match and the answer is still open. That is why the hash cells sometimes read not needed — the comparison genuinely did not need to read either file.
Why this engine exists#
Before it, an executable dropped into TwinScope was line-diffed. The result was pages of mojibake that looked like a diff and meant nothing: every byte sequence that happened to contain a newline became a "line", and every one of them differed.
Answering two questions honestly beats answering the wrong question in detail.
How a file ends up here#
Detection runs in a specific order, and two ordering decisions matter:
- Bytes are decoded before they are sniffed. A UTF-16 file is roughly half NUL bytes; sniffing the raw bytes would write it off as binary before anyone tried to read it. So the first 8 KB are decoded first, and the NUL check runs on the decoded text.
- A known format outranks the sniff. Every PNG contains NULs too. Detection by extension wins for the formats TwinScope can actually read, so an image is routed to the image engine rather than here.
Once both sides do sniff as binary, this engine takes the pair ahead of every other one — nothing else has anything useful to say about them.
What it deliberately does not do#
No hex view, no byte offsets, no attempt to guess at structure. Those would each imply a kind of insight this engine does not have.