September 2026 Version Update

FFXI September 2026 update: client DLL and item-data findings

Comparing an older FFXiMain.dll with the supplied September build revealed two separate kinds of changes: executable code moved, and the client’s resource-data format changed. Other investigators’ item-DAT observations correspond closely to the resource-format changes found in the DLL.

1. Why executable addresses moved

At relative address 0x160B0, an old startup function attempted to load dpnhpast.dll. If loading failed, it returned failure; otherwise, it released the library and returned success.

The new function simply returns success without attempting the load.

Its actual instructions shrank from 28 bytes to 3 bytes. Executable functions have padding between them for alignment, so the total space occupied before the next function decreased from 32 bytes to 16 bytes. The next function consequently moved from 0x160D0 to 0x160C0, and much of the subsequent code moved backward by 16 bytes.

A separate 48-byte padding block at old addresses 0x309E10–0x309E3F also disappeared. The following code therefore moves backward by 64 bytes overall.

This explains the broad address shifts without implying that every relocated function changed behavior. Some smaller helper functions also changed ordering, so there is no universal “subtract 16” or “subtract 64” rule.

These addresses are relative to the DLL’s loaded base, not positions in the compressed file. The findings establish removal of one dependency check—not removal of an entire networking subsystem.

2. The client now expects larger resource records

The DLL’s resource loader changed from expecting records of 0xC00 bytes (3,072 bytes) to 0x1400 bytes (5,120 bytes).

This was verified in three operations:

Calculating where a record begins in its file.
Requesting the number of bytes to read.
Checking that the completed read has the expected length.

All three changed consistently. In practical terms, the client now moves through the relevant files in larger steps and expects a larger block for each record.

Other investigators report exactly the same record-size change in item DAT files. This directly connects the updated reader in FFXiMain to the revised files it reads.

Their analysis reports that the additional 2,048 bytes are trailing padding, rather than additional item information. It also identifies moved header fields and category-specific text locations. Some categories reportedly retain their previous text locations, so applying one blanket adjustment would be incorrect.

They further report that Japanese and English item files were converted while German and French retained the older record size. Those details require format handling appropriate to the individual file.

3. The game’s in-memory structures changed too

The file record and the game’s processed representation of it are different things. The client loads a record, then keeps working information and selected metadata in memory for reuse.

The DLL comparison established:

Internal component Before After
Resource-record payload 3,072 bytes 5,120 bytes
Containing working/cache object 3,500 bytes 5,548 bytes
Separately processed metadata entry 656 bytes 660 bytes

The larger resource-object cache still contains 100 entries. The separate metadata cache still contains 200 entries. Their entries grew; their capacities did not.

In the processed metadata, one value changed from 16 bits at offset +0x06 to 32 bits at offset +0x08, and several following fields moved. Its precise meaning has not been established by this DLL analysis. These offsets describe the processed metadata, not the on-disk header, so they should not be substituted into a DAT-format specification.

The memory-layout change reconciles exactly:

One working object plus 100 cached objects each grow by 2,048 bytes.
200 metadata entries each grow by 4 bytes.
Earlier string and alignment changes reduce the layout by 64 bytes.

The net increase is 207,584 bytes, exactly matching the increase in FFXiMain’s data-section virtual size. This is a declared layout change, not a measurement of total running-game RAM usage or evidence of a memory leak.

It also explains why some later data addresses move forward while much of the executable code moves backward: code and data underwent different changes.

4. How the incorrect descriptions fit

An item-DAT analysis reports that the updated English descriptions literally contain:

Item Reported description
Miracle Cheer 7
Grenade Core 8
Falcon Eye 9

The same analysis reports intact Japanese descriptions. Miracle Cheer’s consistent in-game display of 7 agrees with that finding.

If the reported decoded DAT contents are correct, these particular display errors originate in the supplied English text. The consecutive numbers suggest a possible content-export mistake, but the exact process that produced them has not been demonstrated.

These description errors occur in the files involved in the resource-format update. They do not explain the executable-address shift, which has the separate cause described above. The reported corruption of a zone-name ending has not yet been connected to either mechanism.

Evidence and scope

The FFXiMain findings above were established by offline binary comparison and inspection of the relevant instructions. The additional DAT details—including category/language differences, trailing padding and literal description contents—come from another investigator’s reported analysis and have not been independently rechecked here.

For reproducibility, the compared FFXiMain SHA-256 hashes are:

Before:
6f8844eb7f0380f30a3db2fc3c435e1145f5c450bdd0999133cc75c516ec3c3b

After:
f2245d1c9d06e02c36624942483913f5120c0d40777fc1bb8703c6f4bda823e4

Both files are 2,901,584 bytes on disk. Their matching file sizes conceal changes inside the compressed executable and its memory layout.

This comparison identifies concrete changes and connects the resource reader to the revised item-file format. It is not a complete source-code comparison or a diagnosis of every problem introduced by the update.