Metin2 mit 32 oder 64 Bit: Spiel-EXE und 4-GB-Flag prüfen

Ein Metin2-Client kann ein 32-Bit-x86-Programm bleiben, obwohl er unter 64-Bit-Windows läuft und das Large-Address-Aware-Flag gesetzt ist. Dieses Flag, das häufig mit einem „4-GB-Patch“ verbunden wird, betrifft den Adressraum. Ein nativer x64-Client ist ein anderer Build mit einer anderen Maschinenarchitektur. Keine der beiden Angaben belegt für sich genommen höhere FPS oder eine Lösung für jeden Absturz.

Die erste sinnvolle Frage lautet: Welche Architektur hat die eigentliche Spiel-EXE? Die Windows-Anforderungen eines Servers, sein Launcher und der Spielprozess können unterschiedliche Dinge beschreiben. Dieser Leitfaden erklärt eine reine Lesekontrolle des EXE-Headers und die Grenzen des Ergebnisses. Er setzt nicht voraus, dass alle Metin2-Server denselben Client ausliefern.

Generierte Illustration nach Metin2-Spielreferenzen. Kein Screenshot, keine Speichermessung und kein Nachweis eines bestimmten Clientbuilds.

Microsofts LAA-Dokumentation und die Tabellen zu Speichergrenzen unterscheiden den virtuellen Adressraum eines Prozesses vom eingebauten physischen RAM. Die Zeilen zu den Speichergrenzen setzen eine x64-Ausgabe von Windows voraus. Die ARM64-Zeile identifiziert eine andere Dateiarchitektur; sie besagt nicht, dass diese Datei unter x64-Windows läuft.

Das sind Adressraumgrenzen. Sie versprechen weder die Zuweisung eines einzigen zusammenhängenden 4-GB-Blocks noch die Nutzung deines gesamten RAMs oder das Ausbleiben jeder fehlgeschlagenen Speicheranforderung. Auch ein natives x64-Image mit gelöschtem LAA-Flag unterliegt zusätzlichen Einschränkungen. Leite seine wirksame Grenze deshalb nicht allein aus „64-Bit“ ab.

Umgekehrt beseitigen 32 GB physischer RAM die Adressraumgrenze eines x86-Prozesses nicht. Ihre Erhöhung hilft nur bei Problemen, die tatsächlich davon abhängen. Eine beschädigte Ressource, ein ungültiger Zeiger oder ein inkompatibles Modul erfordert eine eigene Diagnose.

In der Turkmmo-Diskussion vom Mai 2026 nennt der Autor eine MartySama-v5.8-Basis und berichtet, dass der 64-Bit-Build des Servers einfacher gewesen sei als die Portierung des Clients. Die Antworten behandeln die parallele Pflege von x86- und x64-Versionen sowie die Paketkompatibilität. Das sind Berichte über seine konkrete Quellcodebasis, kein getestetes Migrationsverfahren für einen anderen Server.

Eine unabhängige Reddit-Diskussion über einen Linux-Server und x64-Client zeigt eine weitere Unklarheit: Auf die Frage, ob er den Client selbst portiert habe, antwortet der Autor, er habe ihn von jemand anderem übernommen. Ein Screenshot oder eine Serverportierung belegt nicht die Herkunft, Revision und Architektur jeder Komponente.

Der EterNext-Devlog vom 1. April 2026 kündigt einen nativen 64-Bit-Client für dieses bestimmte Projekt an. Wir haben dessen aktuelle Programmdatei nicht untersucht und seine Leistungsversprechen nicht reproduziert. Behandle die datierte Aussage eines Betreibers als Information zu diesem Projekt und prüfe den tatsächlichen Build, bevor du sie auf einen anderen Client überträgst.

Ermittle zuerst die Programmdatei, die das Spiel ausführt. Patcher, Updater und Konfiguration können getrennte Dateien mit unterschiedlichen Architekturen sein. Prüfe die Betreiberunterlagen oder den Namen des Spielprozesses im Task-Manager. Gehe nicht davon aus, dass jeder Privatserver denselben Dateinamen verwendet.

Die PE/COFF-Spezifikation von Microsoft definiert das Feld Machine, das Format des optionalen Headers und das Flag IMAGE_FILE_LARGE_ADDRESS_AWARE. Der folgende Python-3-Leser nutzt ausschließlich die Standardbibliothek und öffnet die gewählte Datei im binären Lesemodus. Speichere ihn als pe_info.py und führe anschließend python pe_info.py client.exe aus. Ersetze den letzten Dateinamen durch die zuvor identifizierte Spiel-EXE.

import json
import struct
import sys

def inspect_pe(path):
    with open(path, "rb") as f:
        size = f.seek(0, 2)
        f.seek(0)
        dos = f.read(64)
        if len(dos) != 64 or dos[:2] != b"MZ":
            raise ValueError("Missing DOS header")
        offset = struct.unpack_from("<I", dos, 0x3C)[0]
        if offset < 64 or offset + 26 > size:
            raise ValueError("PE offset outside file")
        f.seek(offset)
        header = f.read(24)
        if header[:4] != b"PE\0\0":
            raise ValueError("Missing PE signature")
        machine = struct.unpack_from("<H", header, 4)[0]
        optional_size, flags = struct.unpack_from("<HH", header, 20)
        if optional_size < 2 or offset + 24 + optional_size > size:
            raise ValueError("Truncated optional header")
        magic = struct.unpack("<H", f.read(2))[0]
        expected = {0x014C: 0x010B, 0x8664: 0x020B, 0xAA64: 0x020B}
        if machine not in expected or magic != expected[machine]:
            raise ValueError("Unsupported or inconsistent Machine/Magic")
        return {
            "Machine": f"0x{machine:04X}",
            "Format": "PE32" if magic == 0x010B else "PE32+",
            "LAA": bool(flags & 0x0020),
        }

if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("Usage: python pe_info.py client.exe")
    print(json.dumps(inspect_pe(sys.argv[1]), indent=2))

Lies die Felder gemeinsam. Die Kombination aus Machine:0x014C, Format:PE32 und LAA:true bezeichnet ein als large-address-aware markiertes x86-Image, keine native x64-Programmdatei. Machine:0x8664 zusammen mit PE32+ identifiziert AMD64; 0xAA64 steht dagegen für ARM64. Diese Bezeichnungen stammen aus Microsofts Spezifikation und werden nicht aus dem Dateinamen abgeleitet.

Der Leser prüft DOS-/PE-Signaturen, Headergrenzen und die drei unterstützten Machine/Magic-Paare. Er ist ein kleiner Metadateninspektor und kein vollständiger PE-Lader-Prüfer, Signaturprüfer oder Nachweis, dass sich eine Datei sicher ausführen lässt. Bei einem nicht unterstützten oder widersprüchlichen Header solltest du die Ausgabe nicht weiter interpretieren. Sie ist keine Aufforderung, die EXE zu reparieren. Das Skript verändert keine Header und führt die Datei nicht aus.

Microsofts Leitfaden zur Portierung von Spielen nennt Zeigerverkürzung, Ausrichtung, gespeicherte Binärlayouts und Fremdbibliotheken als Migrationsprobleme. Gewöhnliche native DLLs, die im selben Prozess geladen werden, müssen dessen Architektur entsprechen. Eine x86-DLL wird durch Umbenennen nicht zur x64-Abhängigkeit.

Prüfe in einem Metin2-Quellbaum den Code, der Zeiger oder Längen in schmaleren Integern speichert, die Python/native-Schnittstelle, Ressourcendecoder und die Bibliotheken der konkreten Revision. Baue danach die passenden Abhängigkeiten. Der genaue Aufwand ist projektabhängig; die Aufzählung ist kein installierbarer Patch für ein unbekanntes Quellpaket.

Trenne Architektur und gemessene Leistung. Vergleiche dieselbe Clientrevision, Ressourcen, Szene und Einstellungen und erfasse neben Frametimes auch die Bedingungen speicherbedingter Fehler. Microsoft fordert nach einer Portierung ein erneutes Profiling. Für diesen Artikel haben wir keinen FPS-Gewinn eines x64-Metin2-Builds gemessen.

Das Netzwerk überträgt Bytes, keine CPU-Bezeichnung des Clients. Ein 32-Bit-Client und ein 64-Bit-Server können zusammenarbeiten, wenn ihr tatsächliches Protokoll kompatibel bleibt. Ob das für ein bestimmtes Metin2-Paar gilt, muss anhand seiner Paketdefinitionen und Tests geprüft werden. Gleiche Servernamen oder eine erfolgreiche Kompilierung belegen diese Kompatibilität nicht.

Das folgende Beispiel veranschaulicht ein Byteformat und ist keine Metin2-Paketdefinition:

import struct

for fmt in ("<BI", "<BQ"):
    packet = struct.pack(fmt, 1, 1000)
    print(fmt, len(packet), packet.hex())

Die Ausgabe lautet <BI 5 01e8030000 und <BQ 9 01e803000000000000. Laut Python-struct-Dokumentation legt < Little Endian, Standardgrößen und den Verzicht auf Ausrichtungspadding fest. I belegt 4 Bytes, Q dagegen 8. Allein die Verbreiterung dieses Feldes verändert die Nachricht von 5 auf 9 Bytes. Ein Empfänger, der das alte Layout erwartet, benötigt eine abgestimmte Protokolländerung statt der Annahme, die neue CPU-Architektur werde das erledigen.

Dasselbe gilt für gespeicherte Binärdaten und Ressourcenformate. Bewahre explizite Übertragungs- und Dateiverträge oder versioniere Änderungen bewusst und teste beide Seiten. Ersetze nicht mechanisch jeden 32-Bit-Integer durch einen zeigergroßen Typ: Spiel-IDs, Zähler, Längen und Zeiger erfüllen unterschiedliche Aufgaben.

Für Spieler unterscheidet die Headerprüfung die Architektur der ausgewählten Datei von einer Launcherangabe oder Windows-Anforderung. Nutze die vom Server unterstützte Distribution und frage den Betreiber nach dem enthaltenen Spielbuild. Das Ergebnis prüft weder Anmeldung, Welteintritt und Stabilität noch die Kompatibilität mit dem Schutzsystem dieses Servers.

Als Betreiber solltest du einen nachweislich funktionierenden Build bewahren, während du die Quellen und Abhängigkeiten untersuchst, die dir gehören oder die du lizenziert nutzen darfst. Öffentlich lesbarer Quellcode, ein Downloadlink und eine Open-Source-Lizenz sind unterschiedliche Sachverhalte. Dieser Artikel empfiehlt kein ungeprüftes Quellpaket als fertigen 64-Bit-Client.

Wir haben den Leser an vier synthetischen Header-Fixtures und zwei vorhandenen Windows-Programmdateien ausgeführt und unveränderte Dateibytes nachgewiesen. Zehn beschädigte oder widersprüchliche Fixtures wurden abgewiesen. Auch das Byteformatbeispiel lieferte die beschriebenen 5-/9-Byte-Ergebnisse. Diese Kontrollen bestätigen die Beispiele; es wurde kein Metin2-Client gebaut, gepatcht oder gestartet, und es wird kein Ergebnis zur Spielleistung behauptet.

Beginne bei einem anderen Projekt mit dessen aktuellem Build und eigenen Anforderungen. Das Verzeichnis privater Metin2-Server hilft, das passende Profil zu finden. Für einen Client, der bei der Grafikinitialisierung scheitert, behandelt der separate Leitfaden zu No Appropriate Device dieses andere Fehlerbild.

• Microsoft: LAA und 4 GB Adressraum, Speichergrenzen nach Windows-Version, PE/COFF-Format, Spiele auf 64 Bit portieren.
• Python: Standard-Binärformate und Ausrichtung.
• Turkmmo: Migrationsfrage mit benannter Quellbasis und Reddit: Antworten zur Herkunft des Clients.
• EterNext: eigene Migrationsankündigung.

Quellen am 5. November 2026 geprüft. Aussagen der Quellen, EXE-Metadaten und getestetes Spielverhalten bleiben getrennte Nachweise.