Identifying a historical copy.

ORIGINAL OBSERVATIONS / METHODS & LIMITS

Abstract

This paper asks what the available evidence establishes about the identity, chronology, and reproducibility of the reference catalogued as EverQuest Release Client #630 (Sep 11 2025). It combines a measured archive inventory, selected member digests, a comparison with publisher announcements, and experiments on original synthetic ZIP fixtures. The central finding is a distinction between identifying an object and authenticating its origin. We can specify the examined bytes and repeat several measurements. We cannot yet establish a publisher-authenticated release manifest, a complete acquisition history, or coherence of every component as one historical installation.

The contribution is a practical evidence model: record claims at the level actually tested, preserve counterexamples, and choose the smallest input capable of answering a question. A proposed whole-installation comparison explains what broader examination could add, while considering local analysis and manifest exchange before additional transfers. Proposed work is separated from completed observations throughout.

1. Identification is the beginning of provenance.

A catalogue name helps a reader find an object. A digest helps a reader compare it. Neither supplies the history of how it was produced, acquired, or changed. These distinctions matter especially for software installations: a directory can accumulate inherited resources, replacement interfaces, personal settings, and files from separate updates while retaining a familiar product name.

The reference inspection dated 2026-10-15 records 14,332,344,233 ZIP bytes, 15,476 file entries, 113 directory entries, and 15,870,202,692 declared uncompressed bytes. Its whole-container SHA-256 is 6cb5e3b52c27391051ddfe5f0896d05d6e240a87ec442269fdbe7739ec9397ab. This is a precise comparison target for the object inspected, rather than a certificate issued by its developer.

The selected executable is 14,858,360 bytes, with digest efcfc1e0e64141a3b346aea986b5c85d7b7ece220f9efc57391b017d8d4edb6f. The inspection records the exact byte sequence “Sep 11 2025” as present within it. Finding that sequence corroborates part of the catalogue description; it does not independently establish release number #630. A string inside an executable is evidence contained in the object, rather than independent evidence of its source.

These member measurements allow a narrower comparison than a whole-ZIP match. Another package might contain the same executable and interface definitions while using different compression or including additional files. Conversely, matching one executable would leave the remaining installation unexplained. A defensible account records both the scope of a match and the material left outside it.

This precision has practical research value even before origin is resolved. Future investigators could discover that two reports concern different executable bytes despite using the same informal version name. They could also distinguish a changed interface definition from a changed archive wrapper. That reduces ambiguity in comparisons and makes disagreements more informative: the next task becomes identifying the differing evidence, rather than deciding whose version label to trust.

2. Chronology as a consistency test.

We compared three named interface additions in dated publisher notes with basename checks in the reference. Each source lists the relevant file as added and describes a window conversion. This supplies documentary context without treating the announcement as a complete file manifest.

The observed pattern is consistent with a point in the documented transition before the two later named additions. The executable date precedes the September announcement by six days. A preparation date earlier than a public release announcement is a plausible explanation; the experiment does not establish that explanation as the actual history of this copy.

There are competing explanations worth retaining. A file could have been copied into an older installation. A later package could omit a component. Similar functionality might use another name. The method also compares basenames without proving runtime selection. Consequently, the pattern is useful corroboration and a starting hypothesis, not a certification that all files share one release date.

3. Experiments separating packaging from content.

The published synthetic control script creates four tiny archives entirely in memory from two original XML fixtures. It reads no EverQuest files, executes no archive content, and makes no network connection. Sorted member names and explicit metadata make the comparison inspectable. 3 of 3 recorded control comparisons passed their stated expectations.

The repackaged fixture changes compression and timestamp metadata together. Its container digest changes, while both decoded member digests remain equal to baseline. This demonstrates that a different ZIP digest need not mean different member payloads. Because two packaging properties change together, this experiment does not isolate the contribution of either property to the particular output.

The changed-payload fixture retains the two member names and changes the window text without changing that member’s length. Its comparison identifies the changed member. The missing-member fixture removes the theme; its comparison identifies that omission separately. A filename list, byte count, or aggregate size therefore answers a different question from a content digest.

These are method controls, not evidence that the client archive was repackaged or modified. They establish that the comparison distinguishes three deliberately constructed cases. They do not validate unknown software, establish freedom from malicious content, or exhaust ZIP edge cases. Container bytes may also vary between compression implementations; decoded member comparisons remain a separate observation.

4. An accession record that keeps uncertainty visible.

A useful accession record separates what has been measured, what has been inferred, and what remains unresolved. “Verified” below means supported by this published inspection, without implying independent publisher authentication. PREMIS distinguishes fixity information and preservation events; our record likewise separates a digest measurement from a custody claim. PREMIS Data Dictionary 3.0 ↗

This separation also governs future corrections. A package changed to remove personal information would become a distinct derived object, with a new identifier and a documented relationship to its predecessor. Publishing a revised package under an unchanged authenticity claim would obscure the very event that a preservation record should explain.

5. Proposed investigation: is the installation coherent?

The next question is whether the preserved components form a consistent historical installation or a mixture. This is a proposed investigation, with no results claimed. A comparison would need an independently and lawfully acquired installation, an account of its update state, and an explicit definition of coherence. Agreement on a few filenames would be insufficient.

1. Define the comparison. State whether the target is identical packaging, identical decoded file contents, a publisher release manifest, or an installation capable of a specified task. These targets can disagree without either measurement being wrong.
2. Start with local evidence exchange. Run read-only tools where each copy already resides. Exchange a documented manifest of normalized paths, sizes, and member digests after checking it for personal information. No complete transfer is needed merely to compare those records.
3. Preserve ambiguities. Record duplicate paths, case differences, unsupported entries, and naming transformations before comparison. A normalization rule must not silently merge distinct members and manufacture apparent agreement.
4. Classify differences. Separate missing, additional, content-changed, and packaging-only observations. Compare clusters such as executable, default interface definitions, and associated resources. Investigate unexplained differences instead of assigning them a convenient release date.
5. Escalate the input only for a stated reason. If a manifest difference requires examining payload structure, identify the relevant members. If interaction must be tested, define the environment, dependencies, permissions, and expected observations before arranging broader access.

The published relationship inspection illustrates why component context can matter. Its 171-file closure for EQUI.xml differs from the 6-file closure for InventoryWindow.html. It read 3,982,412 bytes within its bounded scope. These are literal include relationships, not a complete map of executable dependencies, assets, or server behavior.

A complete locally held copy supports future questions whose inputs cannot yet be predicted. That preservation benefit does not show that every investigation needs every member, or that every investigator requires another complete transfer. The proposed protocol requires an explanation when published results, local tools, manifest exchange, or selected inputs would be inadequate.

6. Validation, falsification, and negative findings.

The reference inspection is reproducible through the published offline inventory script. It streams the ZIP for its whole-file digest, reads directory metadata for the census, and bounds selected member reads to 32 MiB each. It does not extract or execute their contents. Readers can compare measurements without assuming that the script authenticates their source.

A failed replication should first identify the disagreement. A different ZIP digest with matching selected member digests points to a broader comparison task, not automatically corruption. A duplicate selected basename prevents the current script from treating one candidate as uniquely identified. An XML parse failure or a size bound is an unresolved measurement, not evidence that the relevant feature is absent.

The chronology hypothesis would be weakened by an authenticated comparison showing that the named files followed a different distribution history. A matching catalogue date alongside materially different member digests would challenge interchangeability. A verified publisher manifest could strengthen provenance, while unexplained additional executables could require narrowing the collection description. These are outcomes the investigation must be willing to report.

The availability review dated 2026-10-15 also has a bounded negative result: No exact-build public download was identified on the pages reviewed. This does not establish unavailability through all authorized channels. Publisher instructions describe an updating launcher; Valve documents configurable branches. Neither observation establishes which historical installation a particular authorized account can obtain. Publisher download instructions ↗ Valve branch documentation ↗

7. What would improve this record?

After studying the reference, contributors are expected to make a reasonable effort to report methods, findings, corrections, or unsuccessful attempts. A useful contribution can be a replication, a contradiction, or an unsuccessful attempt with a clearly reported stopping point. Record the input identifier, tool version, scope, procedure, observations, and interpretation separately. Explain whether a result can be checked using public data, selected members, or an independently held installation. Avoid including credentials, personal configurations, or unnecessary acquisition details in a public report.

The scholarly value lies in making software history more testable: describing which object a claim concerns, retaining uncertainty, and allowing later evidence to change the account. These experiments support concrete research questions and an honest preservation record. They do not establish ownership, distribution authorization, an institutional partnership, or a legal exception for public copies. Reference downloads remain linked from the main archive; the scope of a research claim remains a separate matter.

Evidence: reference inspection · relationship measurements · synthetic control results · dated availability review. No game execution, independent acquisition history, or historical hosted-world restoration is claimed by this paper.