PURPOSE & RESEARCH CONTRIBUTION
Software history is also maintenance history.
This collection and its download service are maintained solely to support historical preservation, education, and technical research. Its subject is a particular reference copy, examined as evidence of continuing software development. Access is free, with no advertising or sale of the software.
A release records choices that a current installer can obscure: which interface representations coexist, how features are named, and which parts of a much larger system survive locally. Studying these choices makes a game client useful to the history of human–computer interaction, software maintenance, and networked culture.
The collection publishes an aggregate inventory, cross-file relationships, dated comparisons, original commentary, and repeatable method tests. Static client observations and completed synthetic controls are labeled separately. Methods and limits are disclosed; teaching activities remain proposed. No gameplay experiment or peer review is claimed.
IDENTIFYING THE RESEARCH OBJECT
An expansion name is not a version.
The Outer Brood launched on December 3, 2024. This collection is catalogued as Release Client #630 (Sep 11 2025), 282 days later. A date-bound reference prevents later features from being projected backward onto an earlier build. Publisher launch announcement ↗
Provenance limit: the executable contains “Sep 11 2025.” This corroborates the catalogued date, but does not independently authenticate its publisher, establish #630, or identify a historical server state. Checksums identify bytes; they do not establish authorship or permission.
Reference checksum and inspection record
- ZIP SHA-256
6cb5e3b52c27391051ddfe5f0896d05d6e240a87ec442269fdbe7739ec9397ab- Executable SHA-256
efcfc1e0e64141a3b346aea986b5c85d7b7ece220f9efc57391b017d8d4edb6f- Inventory
- 15,476 files + 113 directory entries; 15,870,202,692 uncompressed bytes.
- Inspected
- October 15, 2026 · The current ZIP matches this reference checksum.
CLIENT, ACCOUNT & HOSTED WORLD
A client within a larger online system.
The stored client is one component of a client/server MMORPG. Its complete online experience also depends on compatible server infrastructure and account state. Daybreak’s EULA describes an account in good standing, software, suitable hardware, and an internet connection as requirements for play. It also describes continuing changes and updates. Daybreak EULA, §§1.2–1.5 ↗
| Part | What this collection provides |
|---|---|
| Archived client files | A reference executable, interface definitions, and accompanying resources for historical inspection. |
| Account and entitlements | No account, subscription, purchase entitlement, or authorization to access a service. |
| Compatible hosted world | No operated game server or reconstruction of its historical world state. |
The catalogued September 11, 2025 build predates later documented development. For example, the September 16, 2026 notes record a client mouse-input correction and changes to EQUI_BazaarSearchWnd.xml. This establishes subsequent updates; it does not establish whether this particular archived copy can connect today. September 2026 publisher update ↗
The collection offers a historical reference for study. Current official installation channels are linked in the availability review. Compatibility, official support status, and market substitution were not tested; possession of these files alone supplies no access grant to Daybreak’s MMORPG service.
THREE IN-DEPTH PAPERS
Follow the evidence further.
Extended arguments, explicit methods, comparison tables, controls, competing explanations, and testable next questions. Original analysis of this reference, with primary sources linked where used.
How an interface holds together.
Composition, classification, and changing rules in a dated client.
Read the full paper →02PROVENANCE & REPRODUCIBILITYIdentifying a historical copy.
Digests, chronology, control experiments, and an evidence register.
Read the full paper →03PRESERVATION & SERVICE CONTEXTWhat should survive?
A client artifact, its surrounding service, and testable preservation goals.
Read the full paper →EIGHT CONNECTED STUDIES
What the evidence can teach us.
SOFTWARE COMPOSITION / MEASURED OBSERVATIONS
A software release extends beyond its executable.
Question. What is lost if a historian keeps only the main program?
Method and result. We counted the reference ZIP’s directory entries and aggregated uncompressed sizes by filename extension. The 14,858,360-byte eqgame.exe represents only 0.094% of the 15,870,202,692 uncompressed bytes. The installation is a collection of components.
| Extension | Files | Uncompressed bytes |
|---|---|---|
.wav | 3,977 | 1,060,553,502 |
.eqg | 2,573 | 10,131,920,050 |
.dds | 1,880 | 188,627,998 |
.txt | 1,773 | 113,292,195 |
.s3d | 1,134 | 1,849,198,691 |
.png | 897 | 50,248,738 |
.mp3 | 803 | 1,104,064,704 |
.tga | 505 | 118,954,718 |
Interpretation. Retaining program code while losing interface definitions or accompanying media would retain a different research object. Counts help plan documentation and storage, but do not measure artistic importance. Extension labels have not been validated against file signatures.
Why it matters. Students can study packaging and dependency questions without assuming an installation equals its source code or a complete online service. Matthews and colleagues’ preservation framework distinguishes components, operating context, and the properties a preservation effort needs to retain. Matthews et al., Framework for Software Preservation (2009), §§6–8 ↗
Use the CSV to distinguish file-count concentration from byte-size concentration. Produce a preservation priority matrix, explain its assumptions, and list what the census cannot tell you about dependencies or behavior.
Explore the full paper: methods, evidence & open questions →
SOFTWARE MAINTENANCE / MEASURED & DOCUMENTARY EVIDENCE
Two interface generations in one reference copy.
Question. How can an established application change its presentation technology while carrying existing interfaces forward?
Historical record. In May 2023, the developer introduced a new UI engine for four windows, left others unchanged, and provided a conversion tool for custom interfaces. The stated aim included scaling while keeping a familiar appearance. This documents an incremental transition. May 2023 UI-engine launch ↗
Artifact observation. Both EQUI_RespawnWnd.xml (3,950 bytes) and RespawnWnd.html (2,036 bytes) occur in the reference. XML totals include structural and property elements; these are not counts of visible controls.
| File | Bytes | Static observation |
|---|---|---|
EQUI_KeyRingWnd.xml | 29,492 | 728 XML elements |
EQUI_RespawnWnd.xml | 3,950 | 96 XML elements |
RespawnWnd.html | 2,036 | 11 HTML start tags |
InventoryWindow.html | 962 | 11 HTML start tags |
CastingWindow.html | 1,151 | 8 HTML start tags |
Analysis. Coexisting XML and HTML representations expose a maintenance problem a screenshot cannot capture: presentation technologies can change while recognizable windows endure. Researchers can investigate compatibility commitments, migration pacing, and the difference between visual and technical continuity.
Limits. Packaging both files does not establish which was loaded, whether fallback worked, or whether one performed better. File totals cannot measure the percentage of windows migrated. No runtime migration or usability experiment was performed.
Connect selected files to dated publisher announcements. Mark every claim as observed, publisher-reported, or inferred. Specify a lawful, isolated runtime experiment needed to test one inference; that experiment remains proposed.
Explore the full paper: methods, evidence & open questions →
HUMAN–COMPUTER INTERACTION / HISTORICAL COMPARISON
Inventory becomes a classification problem.
Question. How does a mature interface organize a growing collection around what an item does?
Evidence. December 2024 notes introduced an Activated Item Key Ring and an “Activated” search category in Bazaar and Find Item. The reference contains EQUI_KeyRingWnd.xml (29,492 bytes), containing the text “activated” (case-insensitive match). December 2024 update ↗
Analysis. A function-based category connects storage and retrieval: naming a category shapes the questions an interface makes easy to ask. This offers a case for teaching information architecture and vocabulary design. Markup supplies evidence of representation, without establishing eligibility rules or proving faster searching.
Longitudinal comparison. In February 2026, the publisher allowed expendable items in that key ring. A name can remain stable while category membership changes. That later announcement does not establish September 2025 rules. No second client was inspected. February 2026 update ↗
Create a dated classification table: category, documented inclusion rule, source, and uncertainty. Design a search-task comparison using lawfully obtained versions. Predicted usability benefits must remain hypotheses until measured.
Explore the full paper: methods, evidence & open questions →
DESIGN HISTORY / DOCUMENTARY ANALYSIS
Small feature changes reveal connected systems.
Question. How do character options and progression rules propagate across a maintained world?
Two documented examples. The launch introduced Dark Elf Rangers. Launch record ↗ January 2025 documented their cultural chain-armor access. That January update also removed expansion ownership as a requirement for Aureate’s Bane while retaining its ToB-zone restriction, and added the mercenary ability Defy the Aureate against Curse of Subjugation. January 2025 update ↗
Analysis. One example connects a selectable identity to equipment rules. The other separates ownership, location, and effect. Together they support a teaching model of independently changing predicates, rather than one “feature available” flag.
Historical value and limit. These dated changes make maintenance visible after launch. They support a history of design decisions, not claims about balance, accessibility outcomes, account entitlements, or September server behavior. The examples were not reproduced in gameplay.
Draw a decision table for identity, equipment eligibility, ownership, location, and effect. Source each asserted rule and leave unverified cells unknown. Explain why client files alone cannot fill every cell.
Explore the full paper: methods, evidence & open questions →
DIGITAL PRESERVATION / RESEARCH DESIGN
Keeping the bytes is the first research question.
Question. Which properties have been retained, and which experiences remain outside the evidence?
Preservation analysis. Library of Congress guidance distinguishes unchanged content from usability: rendering may depend on formats, software, hardware, and licenses. Our checksum and inventory provide a reference for comparison; they do not demonstrate restoration of an online world. Library of Congress: bit-level preservation and usability ↗
| Concern | Available evidence | Further evidence needed |
|---|---|---|
| Copy identity | Sizes, hashes, embedded date | Authenticated provenance and release-label verification |
| Interface design | Selected XML/HTML structures | Loaded implementation; accessibility and usability outcomes |
| Online behavior | Dated change descriptions | Server state, entitlements, observed execution |
| Social experience | Technical context and scholarship | Community records, participant accounts, consented research |
Cultural context. T. L. Taylor’s Play Between Worlds (2006) is an actual scholarly study of EverQuest’s social world, including work and play, identity, and commercial culture. It establishes scholarly context, not findings about this 2025 build. A client can complement social history, but cannot stand in for its participants. Taylor, MIT Press ↗
Write an adequacy plan for interface, maintenance, or social history: significant properties, missing evidence, ethical constraints, and a test of preservation success. A future oral-history project would require consent; none is claimed here.
Explore the full paper: methods, evidence & open questions →
COMPONENT RELATIONSHIPS / MEASURED GRAPH & CONTROLS
An interface assembled from many files.
Question. What relationships disappear when a historical interface is reduced to one file? We selected five named roots across two default-interface trees, uifiles/default and uiresources/default; 5 unique roots were inspected. Unmatched or ambiguous root requests remain visible below. The method follows literal XML Include text and HTML include-body[file] references. This is a completed static examination, rather than a rendering experiment.
Method. The offline script resolves paths relative to each referring member, preserves case, and distinguishes exact matches, unique case-only matches, ambiguity, and unmatched references. It follows matched includes within declared limits, records hashes, and never extracts, executes, or fetches resources. Duplicate candidates are not guessed.
Measured result. The union of reached nodes contains 180 files, representing 3,982,412 uncompressed bytes, with 175 recorded include occurrences. Shared components count once in that union. Each row below instead describes one root’s reachable set, so rows may overlap.
| Fixed root | Files reached | Archive available | Root alone | Matched subset |
|---|---|---|---|---|
EQUI.xml | 171 | 170 | 0 | 170 |
InventoryWindow.html | 6 | 5 | 0 | 5 |
RespawnWnd.html | 1 | 0 | 0 | 0 |
CastingWindow.html | 1 | 0 | 0 | 0 |
ClaimWindow.html | 1 | 0 | 0 | 0 |
Inventory example. The 962-byte InventoryWindow.html belongs to a matched include graph of 6 files totaling 159,775 bytes. Keeping the entry alone retains references without the accompanying fragments. Reading these resources together enables study of how presentation is divided across files, and supplies a baseline for investigating later maintenance changes. This is evidence of modular representation, without establishing load order, rendered appearance, performance, or independent replaceability.
Controlled omission. For InventoryWindow.html, excluding uiresources/default/windows/InventoryWindowInv.html from the recorded availability set removes 1 available graph edges. Both incoming and outgoing edges involving that file can be lost. These masks change graph membership only. They demonstrate sensitivity to a known omission, not a failed load, unusable window, or measured gameplay effect.
Independent value. The graph makes composition and reuse inspectable across files, beyond counting tags in isolated documents. Students can distinguish a reference occurrence, a distinct target, a shared component, and an assumption about execution. An unmatched path means no match under this model; it does not establish a broken client or absent engine resource.
| Input | What it supports | Limit |
|---|---|---|
| Published graph | Review counts, relationships, and controls | Cannot independently reparse source files |
| Roots and matched subset | Repeat the recorded include analysis | Scope excludes other resource forms and runtime selection |
| Broader installation | Investigate questions beyond this sample | This study does not require the whole client or prove public-distribution necessity |
Limits. No node or edge limit truncated traversal. 0 reached nodes were not parsed as HTML/XML includes; consult their recorded statuses. CSS, JavaScript, images, engine-generated relationships, rendering, and server behavior are outside scope. A matched subset is sufficient only for the recorded relationships, not proven functional completeness.
Data and repeatable method
Relationship record (JSON) · Include graph (CSV) · Offline inspection script (Python)
The record identifies the ZIP checksum and inspection date. Member reads are limited to 2,097,152 bytes each and 33,554,432 bytes in total. Read 3,982,412 member bytes during this examination; whole-ZIP hashing is a separate pass.
Identify shared targets, compare edge occurrences with distinct files, and reproduce one availability mask. State which additional evidence a runtime claim would need.
Explore the full paper: methods, evidence & open questions →
VERSION HISTORY / DOCUMENTARY CROSS-CHECK
A release date needs corroborating evidence.
Question. How closely does this reference copy align with a documented sequence of interface changes, and what can that alignment establish?
Method. We compared three exact HTML basenames against the ZIP directory census. Separately, we read the publisher’s dated update notes, which identify the respective windows as converted and list the files under “Added.” The table joins independently recorded observations; it does not treat a patch announcement as a signed manifest.
| Dated publisher record | File listed as added | Reference observation |
|---|---|---|
| September 17, 2025 ↗ | ClaimWindow.html | 1 matching file · 2,712 bytes |
| October 15, 2025 ↗ | SendMoneyWnd.html | No matching basename |
| January 21, 2026 ↗ | BankWindow.html | No matching basename |
Result. The reference contains the Claim definition; the two other basenames were not found. This is consistent with a point in the documented transition before those later additions. It is a useful comparison against the broader claim that every version bearing the same expansion name is interchangeable.
Build date and release date. The executable contains “Sep 11 2025,” six days before the September announcement. Preparing a build before announcing its release is a plausible explanation for that sequence. This inspection cannot establish its actual preparation, shipment, installation, or modification dates. Those remain separate provenance questions.
Interpretation. A dated software artifact can support a history of maintenance through the relationship between present and absent components. Here, the comparison supplies a falsifiable reference: another researcher can repeat the basename checks and challenge the interpretation using better provenance evidence. That is more informative than assigning an era from appearance alone.
Limits. Consistency does not authenticate the publisher, independently establish release number #630, or prove that every file belongs to one date. The ZIP may contain inherited or modified material. Absence of a basename does not establish absence of equivalent functionality. No later client was inspected, and these observations do not reconstruct a historical server state.
Construct a provenance argument with three columns: observation, interpretation, and evidence still needed. Explain how a publisher-authenticated manifest or independently acquired comparison copy could strengthen or overturn each conclusion. Preserve conflicting evidence instead of silently normalizing the dates.
Explore the full paper: methods, evidence & open questions →
REPRODUCIBILITY / COMPLETED SYNTHETIC CONTROLS
An archive can change while its files stay the same.
Question. Does a different archive checksum necessarily mean the software files inside changed?
Controlled experiment. We authored two tiny XML files for this method test and created four ZIPs entirely in memory. The baseline uses stored entries. A second ZIP contains exactly the same named files, with different timestamps and DEFLATE compression. A third changes one label in one XML payload; a fourth removes the other file. Each comparison had a declared expected outcome. No client files, game execution, network connection, or extraction were involved.
| Control | ZIP digest | Member comparison | Result |
|---|---|---|---|
| Same XML, different packaging | Different | Identical member set and digests | Matched prediction |
| One XML payload changed | Different | Changed member detected | Matched prediction |
| One member removed | Different | Missing member detected | Matched prediction |
Result. Repackaging changed the whole-ZIP SHA-256 while preserving every member’s name, byte length, and digest. The payload-change control identified the altered file while the other file retained its digest. The missing-member control detected an absent file rather than treating the surviving matching payload as a complete match. All three predicted outcomes were observed.
Why it matters. A release citation needs to distinguish a particular container from its contents. An archive digest answers whether the ZIP bytes match a reference; member digests help locate a difference and compare payloads across packaging changes. Keeping both levels makes a preservation record more useful to later researchers and avoids treating a changed timestamp or compression choice as evidence of changed program logic.
Scope. These are synthetic controls for the measurement method, not observations about EverQuest’s packaging history or behavior. Matching payloads do not prove a publisher origin, a complete installation, successful execution, or equivalent software behavior. This experiment establishes no need for a complete client download. Fixed inputs repeat within the same ZIP/DEFLATE implementation; other compressors may change container bytes while member digests remain comparable.
Control data and digests ↗ Run the original method ↗
Explore the full paper: methods, evidence & open questions →
OPEN METHODS & RESEARCH OUTPUTS
Make the observations repeatable.
The outputs publish measurements rather than copied artwork, interface source text, or personal configuration. Readers can examine these results without retrieving the complete client. Researchers with a lawfully held copy can repeat the inspection.
- Identify. Stream-hash the ZIP; enumerate the directory and aggregate entry sizes.
- Sample. The first inspection reads fixed files, at most 32 MiB each. The relationship study uses separately declared limits: 2 MiB per member, 32 MiB total, 512 nodes, and 2,048 edges.
- Compare and control. Keep measurements, dated publisher reports, and interpretations distinct. Availability masks test the recorded graph; authored synthetic fixtures test the fixity method.
- Bound the conclusions. No client extraction, binary execution, game-service connection, source-code reconstruction, or malware assessment was performed.
python inspect-reference.py CLIENT.zip > reference.jsonpython inspect-ui-relationships.py CLIENT.zip > ui-relationships.json
Python 3, no added packages. Hashing reads the whole ZIP and can take several minutes. Dates differ between runs. Extension counts are not format validation. Absent or duplicate selected filenames are reported without guessing which to inspect. The synthetic controls use original authored fixtures and do not read the client.
PREMIS distinguishes an object’s fixity information from preservation events. We publish a digest and dated inspection to support later comparisons; this is a small reference record, not a claim of institutional custody or PREMIS certification. PREMIS Data Dictionary 3.0: fixity and events ↗
HISTORICAL AVAILABILITY / BOUNDED EVIDENCE REVIEW
Current access is a different question from historical identity.
Reviewed October 15, 2026. We examined public publisher and Valve pages to ask whether they identified an authorized public download matching this particular reference. The target was the catalogued release and its published ZIP checksum, rather than any installation carrying the EverQuest name.
| Source | What was observed | What remains untested |
|---|---|---|
| Publisher download instructions ↗ | Describes latest LaunchPad and automatic updates when logging in. | Public instructions reviewed; installer payload, account options, and publisher support were not tested. |
| Official Steam storefront ↗ | Official app 205710, free-to-play listing, Daybreak account requirement. No explicit matching historical-build link identified in the retrieved storefront. | Authenticated branches, depots, manifests, and entitlement conditions were not inspected. |
| Valve platform documentation ↗ | Publishers can manage separate branches and control access. | General platform documentation; not evidence of EverQuest-specific available versions. |
Finding. No exact-build public download was identified on the pages reviewed. This does not establish unavailability through all authorized channels. The publisher instructions describe a route that updates an installation; the Steam storefront establishes another official distribution channel. Neither retrieved page supplied a link explicitly matching this reference’s designation and checksum. A current installation path therefore does not, by itself, authenticate or reproduce this historical object.
Scope. This was a document review. We did not log in, execute an installer, retrieve Steam depots, inspect authenticated branch choices, or ask publisher support. Valve’s general description of branches explains how access can vary; it does not establish which EverQuest versions a particular account can obtain. A third-party mention of a manifest would likewise require verification of contents and access conditions.
Why record uncertainty? Historical availability is an empirical question that can change. Recording the date, channels, and untested paths makes this finding open to correction. It avoids treating failure to identify a download on a small set of public pages as proof that no authorized source exists.
Next evidence needed. A publisher-authenticated reference manifest, a verified authorized historical branch, or a documented support response could materially improve the record. None is claimed here. This review establishes neither distribution authorization nor market effects.
Download the dated availability review · JSON →REPRODUCIBILITY & THE AMOUNT OF MATERIAL NEEDED
When does a complete copy matter?
Preserving an exact artifact and studying selected features are different tasks. A reproducibility claim should say which bytes are necessary and why a smaller research output is insufficient.
| Task | Necessary input | Status here |
|---|---|---|
| Verify whole-archive fixity | Every byte of the ZIP; a partial hash cannot verify the complete object | Completed; digest published |
| Reproduce the census | ZIP directory metadata; file payloads are unnecessary for these counts | Completed; aggregate CSV published |
| Repeat interface measurements | The selected definitions; the entire installation is unnecessary | Completed; measurements and method published |
| Reproduce scoped include relationships | The selected roots, matched component subset, and reliable inventory | Completed static graph and availability-mask controls; runtime behavior remains untested |
| Investigate component interaction | A suitable installation, dependencies, and a controlled lawful environment | Future protocol; no execution or results claimed |
Further work. An interaction study could test whether documented UI representations can be selected consistently and which resources they require. It would need a specified environment, a comparison build, repeatable tasks, and a record of dependencies. The dated availability review records what the official public pages establish and what remains untested. Independent researcher demand, archival partnerships, and runtime results require further evidence.
Independent copies can reduce dependence on one storage system, and a complete copy permits later questions not anticipated by today’s measurements. Those preservation benefits do not by themselves establish a right to public distribution. The studies here do not require every visitor to download or seed the full client.
SUPPORTING THE COLLECTION
Keep the purpose with the material.
The collection supports criticism, teaching, historical inquiry, and technical study through original commentary and repeatable observations. Normal download links ask visitors to acknowledge educational, research, and archival purposes and avoid unrelated redistribution.
Copyright and trademark rights remain with their owners. Research value and permission to distribute a complete client are separate questions; this notice grants no additional software license. Any copying or redistribution needs its own lawful basis.
View the reference downloads →After research, contributors are expected to make a reasonable, good-faith effort to share methods, findings, corrections, or unsuccessful attempts when possible. Prepare a contribution. No advance contact or submission is required for access; no submission channel is currently published.