How an interface holds together.

ORIGINAL STATIC STUDY · METHOD 1.1

Abstract

This paper examines how a dated EverQuest client represents interface composition across files. It asks what becomes visible when an installation is studied as a set of explicit relationships rather than as an executable or a collection of screenshots. Five fixed entry files were examined using a bounded, offline include-reference method. The resulting record contains 180 reached files and 175 include occurrences, occupying 3,982,412 uncompressed bytes. An XML entry reaches a broad collection of definitions, while an HTML inventory entry names a smaller group of fragments. These observations support questions about modular presentation, maintenance boundaries, and preservation inputs. They establish neither a complete runtime dependency model nor the operation of a historical online service.

1. The research object and the questions

The object is the reference ZIP catalogued as EverQuest: The Outer Brood, Release Client #630, September 11, 2025. Its digest is recorded in the downloadable data. The embedded date corroborates a date string in the executable, but the investigation does not independently authenticate publisher origin, the release number, or consistency of every installed file. Conclusions attach to this identified copy, not automatically to every installation carrying the same label.

Three questions guide the examination. How are selected presentation resources connected by explicit includes? How much surrounding material does one small entry file name? Which conclusions remain possible when only measurements, isolated files, or a selected subset are available? These questions concern inspectable software structure. A claim about how quickly a window opens, which engine loads it, or what a player experiences would require another method.

2. Selection and bounded inspection

The fixed roots are EQUI.xml in uifiles/default and four HTML windows in uiresources/default/windows: Inventory, Respawn, Casting, and Claim. Selection deliberately includes a broad XML entry and a small HTML sample. It is not random, representative of every window, or sufficient to estimate a migration percentage. Keeping the two directory trees distinct prevents a basename match from silently combining different locations.

The script enumerates archive members, resolves the specified roots, hashes opened members, and parses two forms: XML Include element text and HTML include-body attributes named file. Matched targets enter a queue; a visited set prevents repeated reading. Reads stop at 2,097,152 bytes per member, 33,554,432 aggregate member bytes, 512 nodes, or 2,048 edges. The recorded member reads total 3,982,412 bytes. Whole-ZIP hashing reads the complete container separately.

XML containing DTD or entity declarations is excluded from parsing. HTML with a nonempty base href is flagged rather than resolved using an assumed base. Relative paths are an explicit analytical convention, not a verified reconstruction of the game engine’s resolver. Standard HTML itself makes document base URLs relevant to resolution; that is why ignoring a declared base would be an avoidable assumption. HTML Standard: document base URLs.

3. A graph with a deliberately narrow meaning

Let V be the set of reached archive members. Let E contain one directed edge occurrence for each recognized include, from its referring file to its resolved target when a match exists. Repeated includes remain separate occurrences: a list of references and a set of files answer different questions. In this record, 175 matched occurrences correspond to 175 distinct ordered source–target pairs. Unmatched or unsupported references would retain their classifications rather than become guessed edges.

For root r, define R(r) as the members reachable through matched include edges, including the root. Its byte weight is the sum of each reached member’s uncompressed size, counted once. This weight describes stored representation, not execution cost or importance. Across the graph, only 2 files emit recognized include occurrences. A zero outgoing count means the parser found no supported include form; it does not make a file independent of styles, images, scripts, templates, or executable support.

4. Results: two forms of composition

The XML entry reaches 171 files through 170 occurrences. This makes it a useful catalogue of explicitly named presentation resources under this method. The graph does not establish that every listed definition is instantiated, that each corresponds to one visible window, or that these are all resources the program can use. The large apparent fan-out is a property of the recognized include vocabulary.

The 962-byte inventory entry reaches 6 files totaling 159,775 bytes. Its own bytes represent 0.602% of that selected representation. The other members are InventoryWindowAltCurr.html, InventoryWindowInv.html, InventoryWindowMerc.html, InventoryWindowPersonas.html, InventoryWindowStats.html. These names provide useful indexing clues. Their functional responsibilities still require examining their structures; filenames alone cannot establish behavior.

The three other HTML roots have no recognized includes in this record. This contrast is informative without becoming a quality ranking. It suggests different packaging granularity within the selected sample. It cannot show that the other windows need fewer resources overall, because the method omits resource forms that could dominate their actual operation.

5. Case, ambiguity, and reproducible identity

There is one uniquely matched case-only reference, compared with 174 exact matches. The case-only target is EQUI_PvPLeaderboardWnd.xml. The procedure first seeks an exact path; only a unique case-folded candidate receives the separate classification. Multiple candidates would remain ambiguous. This matters when moving a collection between storage systems with different naming conventions.

The finding is a naming discrepancy under the declared comparison, not a diagnosed defect. No runtime resolver was tested. Furthermore, the public graph retains the canonical target rather than reproducing the original attribute text; its record alone cannot reconstruct the exact original capitalization. Repeating that detail requires the source member. Hashes permit comparison with the measured bytes while leaving provenance and interpretation as separate questions.

6. Templates, taxonomy, and maintenance

The XML tree contains a member named EQUI_Templates.xml, measured at 108,480 bytes. That name and its inclusion establish a candidate for investigating shared presentation definitions. They do not prove which definitions are reused, how inheritance works, or whether modifying one file would affect another. An extension of this study could record named definitions and references to them, with unresolved identifiers retained explicitly.

The separate Key Ring observation supplies a complementary level of description: 728 XML elements, including 6 Page, 6 Listbox, 12 Button, and 12 Template elements. These are tag totals, not counts of visible controls. Equal page and listbox totals do not establish one-to-one containment. A hierarchy-aware analysis would be needed to test that relationship.

These two levels support distinct maintenance questions. Include relationships reveal file composition; element taxonomies reveal a vocabulary of representation. Neither should substitute for the other. A stable filename could conceal a changed element hierarchy, while an unchanged hierarchy could be packaged differently. Comparing both would make a future version study more discriminating than comparing screenshots or file counts alone.

7. Classification and changing rule predicates

An interface category has a history

December 2024 introduced an Activated Item Key Ring, an “Activated” search category, and Dark Elf Rangers. December update. The inspected Key Ring XML contains activated text; this is lexical evidence, not an item-eligibility test.

A useful model separates a category’s label from its membership function, C(item, date). A stable label need not imply a stable function. February 2026 documentation added expendable items to that key ring. Later category change. Comparing dated descriptions exposes that distinction; projecting the later rule onto this reference would erase it. An independent investigation could compare lawfully available item samples and preserve disagreements as observations, without treating XML vocabulary as server authority.

Identity, equipment, ownership, and location

January 2025 documented cultural chain armor for Dark Elf Rangers. It also removed Aureate’s Bane’s expansion-ownership requirement while retaining its ToB-zone restriction. January update.

These examples motivate separate predicates: one connecting character identity and equipment, another connecting an account, location, and an ability’s effect. Collapsing them into one “available” flag conceals which condition changed. Students can construct decision tables with unknown cells, then specify evidence needed for each. A client label, equipment definition, or button cannot fill every cell. The historical contribution is to distinguish dimensions of a maintained design; the documentary examples supply questions, rather than a recovered implementation or a test of live rules.

8. Chronology without an invented migration timeline

The developer’s May 2023 announcement described an incremental UI-engine conversion with a familiar appearance and scaling support. It supplies documentary context for studying architectural change. Publisher announcement, May 17, 2023.

The reference contains XML and HTML resources in different trees, including similarly named Respawn definitions. Coexistence establishes retained representations in this copy. It does not determine when a particular file was introduced, which representation was active, or whether one superseded the other completely. A defensible chronology would pair independently identified builds with dated announcements and preserve contradictions instead of forcing every file into a linear replacement story.

9. Availability masks and their interpretation

For a set of available members A, count a recorded matched edge only when both endpoints belong to A. This is a membership calculation on the previously observed graph. It is not a fresh traversal, simulated engine, or experiment that removes a file from a running installation.

For Inventory, the root-only mask retains 0 matched edges; the resolved subset retains 5. Excluding InventoryWindowInv.html leaves 4 and loses 1. An omission can remove incoming and outgoing occurrences involving that member. Here the control confirms that the graph calculation detects a specified omission. It does not independently validate the parser or prove that the window would fail to load.

10. Inputs, alternatives, and proportional claims

The graph’s 3,982,412 bytes amount to 0.025% of the archive’s uncompressed member bytes. That small fraction is an important constraint on the conclusion: this completed study does not require every texture, sound, or other client component. A complete reference may support unforeseen future questions, but that prospective benefit does not establish that every visitor needs it or determine permission to distribute it.

11. Falsifiable next questions

Three extensions can be specified before collecting additional evidence. First, a later independently identified build may preserve the inventory entry’s references while changing fragment hashes. The hypothesis would be contradicted by a changed include set, even if the interface looked similar. Second, a definition-reference graph may expose shared template identifiers across windows. Mere inclusion of a template-named file would not satisfy that prediction. Third, a controlled execution study may observe resources outside this include graph. Its trace would test the graph’s adequacy for a declared task, rather than retroactively make the static graph complete.

Each extension needs a comparison object, an explicit matching policy, and a record of negative findings. No second-build comparison or execution trace is reported here. The preservation framework’s distinction between retained components and testable adequacy is useful context for designing those tests. Matthews and colleagues, software preservation framework.

12. A teaching and contribution protocol

Next, choose a lawfully held source subset if independent parsing is needed. Record the reference digest, tool version, selected members, and matching policy. Compare member hashes before interpreting differences. Mark each assertion as a direct observation, documentary statement, inference, or untested hypothesis. A disagreement about classification is a useful contribution when it identifies a reproducible example.

Finally, prepare a short methods note containing the question, sufficient inputs, alternatives considered, observed result, and uncertainty. Include an unsuccessful attempt if that is what occurred; a favorable result is unnecessary. Do not publish client assets, personal configuration, credentials, or identifiable participant information with the note. The educational outcome is a defensible chain from evidence to claim, including a clear account of what additional evidence would change the conclusion.

Data and scope of the conclusion

The record reports no node or edge truncation and 0 reached nodes unparsed by the declared include method. This is completeness within the bounded procedure, not completeness of interface architecture. CSS, JavaScript, images, dynamic loading, usability, performance, entitlement, and server behavior were not tested. The contribution is a repeatable description of selected representational relationships and a disciplined basis for further investigation.

Relationship record (JSON) · Include occurrences (CSV) · Offline inspection method · Reference inspection · Reference downloads