# Validation

The reconstructed sources were checked in two ways.

## 1. Header/API syntax check

`des.c`, `undes.c` and the common support compile syntactically against the
actual `crypt.h` from the supplied `cryptl99.zip`.  There are no remaining
placeholder CRYPTLIB declarations.

## 2. Full CRYPTLIB round-trip on a modern compiler

For a behavioural sanity check, the supplied CRYPTLIB 0.99 source and libdes
3.14 source were compiled with GCC 14.2 together with the reconstruction.

A binary test file was then processed as:

```text
plain.bin -> des_v2 -> encrypted.bin -> undes_v2 -> roundtrip.bin
```

`plain.bin` and `roundtrip.bin` compare byte-for-byte equal.

The generated single-block encrypted file has the expected size:

```text
4       version
4       IV
256     password-check block
16384   encrypted data block
-----
16648 bytes total
```

The prefix begins with `75 27 00 00`, i.e. file version `0x00002775` in the
little-endian format used by the DOS executable.

A second test with an incorrect password exits with status 1 and prints the
same executable string:

`Password is not correct, no decryption possible`

## Scope of this validation

This confirms that the reconstructed control flow is internally consistent
with the supplied CRYPTLIB source.  It does **not** prove that a modern GCC
build produces ciphertext byte-for-byte identical to the original Turbo C
build.  The strongest compatibility test would be to decrypt an actual file
created by the 1998 `des.exe`, or run the original executable in a DOS
environment and compare outputs.