Client Metin2 32 ou 64 bits : vérifier l'EXE et le bit LAA

Un client Metin2 peut rester un programme x86 de 32 bits même s'il fonctionne sous Windows 64 bits avec le bit Large Address Aware activé. Ce bit, souvent associé à un « patch 4 Go », concerne l'espace d'adressage. Un client x64 natif est une autre compilation, destinée à une autre architecture machine. Aucun de ces libellés ne prouve à lui seul une hausse des FPS ou la correction de tous les plantages.

La première question utile est : quelle est l'architecture du véritable exécutable du jeu ? Les prérequis Windows du serveur, son lanceur et le processus du jeu peuvent décrire des éléments différents. Ce guide explique comment lire l'en-tête de l'EXE sans le modifier et ce que le résultat permet de conclure. Il ne suppose pas que tous les serveurs Metin2 distribuent le même client.

Illustration générée d'après des références du jeu Metin2. Ce n'est ni une capture d'écran, ni une mesure mémoire, ni la preuve d'une compilation précise.

La documentation LAA de Microsoft et ses tableaux de limites mémoire distinguent l'espace d'adressage virtuel d'un processus de la RAM physique installée. Les lignes sur les limites mémoire ci-dessous supposent une édition x64 de Windows. La ligne ARM64 identifie une autre architecture de fichier ; elle n'affirme pas qu'un tel fichier fonctionne sous Windows x64.

Ce sont des limites d'espace d'adressage, pas la promesse de pouvoir allouer un bloc contigu de 4 Go, d'utiliser toute la RAM ou d'éviter chaque échec d'allocation. Un binaire x64 natif dont le bit LAA est désactivé subit lui aussi des restrictions supplémentaires ; le seul terme « 64 bits » ne permet donc pas de déduire sa limite effective.

À l'inverse, disposer de 32 Go de RAM physique ne supprime pas le plafond d'adressage d'un processus x86. Relever ce plafond ne traite que les problèmes qui en dépendent réellement. Une ressource corrompue, un pointeur invalide ou un module incompatible demande son propre diagnostic.

Dans la discussion Turkmmo de mai 2026, l'auteur indique utiliser une base MartySama v5.8 et rapporte que la compilation 64 bits du serveur a été plus simple que le portage du client. Les réponses évoquent le maintien de distributions x86 et x64 et la compatibilité des paquets. Ces témoignages concernent les sources de cet auteur ; ils ne constituent pas une procédure de migration testée pour un autre serveur.

Une discussion indépendante sur Reddit à propos d'un serveur Linux et d'un client x64 montre une autre ambiguïté : lorsqu'on lui demande s'il a porté le client lui-même, l'auteur répond l'avoir obtenu auprès de quelqu'un d'autre. Une capture d'écran ou le portage d'un serveur n'identifie pas l'origine, la révision ou l'architecture de chacun de ses composants.

Le journal de développement d'EterNext du 1er avril 2026 annonce un client 64 bits natif pour ce projet précis. Nous n'avons pas inspecté son exécutable actuel ni reproduit ses affirmations de performance. Considérez une déclaration datée de l'exploitant comme une information sur son projet ; vérifiez la compilation réelle avant de l'étendre à un autre client.

Identifiez d'abord l'exécutable qui fait tourner le jeu. Le patcher, l'outil de mise à jour et celui de configuration peuvent être des fichiers distincts, avec des architectures différentes. Consultez la documentation de l'exploitant ou le nom du processus du jeu dans le Gestionnaire des tâches ; tous les clients privés n'utilisent pas le même nom de fichier.

La spécification PE/COFF de Microsoft définit le champ Machine, le format de l'en-tête optionnel et le bit IMAGE_FILE_LARGE_ADDRESS_AWARE. Le lecteur Python 3 ci-dessous utilise uniquement la bibliothèque standard et ouvre le fichier choisi en lecture binaire. Enregistrez-le sous pe_info.py, puis lancez python pe_info.py client.exe, en remplaçant le dernier nom par celui de l'exécutable réellement identifié.

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))

Interprétez les champs ensemble. Machine:0x014C, Format:PE32, LAA:true désigne un binaire x86 marqué large-address-aware, pas un exécutable x64 natif. Machine:0x8664 avec PE32+ identifie AMD64 ; 0xAA64 identifie ARM64. Ces identifiants viennent de la spécification Microsoft, et non du nom de fichier.

Le lecteur vérifie les signatures DOS/PE, les bornes des en-têtes et les trois paires Machine/Magic prises en charge. C'est un petit inspecteur de métadonnées, pas un validateur complet du chargement PE, un vérificateur de signature ou une évaluation de la sécurité d'exécution du fichier. Un en-tête non pris en charge ou incohérent doit interrompre l'interprétation, pas inciter à réparer l'EXE. Le script ne modifie aucun en-tête et n'exécute pas le fichier.

Les conseils de Microsoft pour porter des jeux recensent la troncature des pointeurs, l'alignement, les formats binaires persistants et les bibliothèques tierces parmi les points à vérifier. Les DLL natives ordinaires chargées dans le processus doivent correspondre à son architecture ; renommer une DLL x86 n'en fait pas une dépendance x64.

Pour les sources d'un client Metin2, examinez le code qui stocke des pointeurs ou des longueurs dans des entiers plus petits, l'interface Python/native, les décodeurs de ressources et les bibliothèques de cette révision précise. Compilez ensuite les dépendances correspondantes. Le travail exact dépend du projet ; cette liste n'est pas un patch installable pour des sources non identifiées.

Distinguez l'architecture des mesures de performance. Comparez la même révision du client, les mêmes ressources, scène et réglages, en relevant les conditions des erreurs mémoire ainsi que les temps de trame. Microsoft recommande de refaire le profilage après le portage. Nous n'avons mesuré aucun gain de FPS d'une compilation Metin2 x64 pour cet article.

Le réseau échange des octets, pas le libellé du processeur du client. Un client 32 bits et un serveur 64 bits peuvent communiquer si leur protocole réel reste compatible. Pour confirmer qu'une paire Metin2 précise le permet, il faut ses définitions de paquets et des tests ; un même nom de serveur ou une compilation réussie ne le démontre pas.

Voici un exemple de format binaire à titre d'illustration, pas la définition d'un paquet Metin2 :

import struct

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

La sortie est <BI 5 01e8030000 et <BQ 9 01e803000000000000. D'après la documentation Python de struct, < impose le petit-boutisme, des tailles standard et aucun remplissage d'alignement ; I occupe 4 octets et Q en occupe 8. Élargir uniquement ce champ fait passer le message de 5 à 9 octets. Un destinataire qui attend l'ancien format nécessite un changement de protocole convenu, plutôt que l'hypothèse que la nouvelle architecture corrigera tout.

Le même examen s'applique aux données binaires enregistrées et aux formats de ressources. Conservez des contrats explicites pour les échanges et les fichiers, ou versionnez volontairement leurs changements en testant les deux côtés. Ne remplacez pas mécaniquement chaque entier 32 bits par un type de la taille d'un pointeur : identifiants du jeu, compteurs, longueurs et pointeurs n'ont pas le même rôle.

Pour les joueurs, lire l'en-tête permet d'identifier l'architecture du fichier fourni, indépendamment du libellé du lanceur ou des prérequis Windows. Utilisez la distribution prise en charge par le serveur et demandez à l'exploitant quelle compilation du jeu elle contient. Ce résultat ne vérifie ni la connexion, ni l'entrée dans le monde, ni la stabilité ou la compatibilité avec la protection du serveur.

Pour les exploitants, conservez une compilation fonctionnelle connue pendant l'audit des sources et dépendances que vous possédez réellement ou êtes autorisés à utiliser. Des sources publiquement lisibles, un lien de téléchargement et une licence open source sont trois faits distincts. Cet article ne recommande pas un paquet de sources non vérifié comme client 64 bits prêt à l'emploi.

Nous avons exécuté le lecteur sur quatre fichiers synthétiques d'en-tête et deux exécutables Windows existants, en vérifiant que leurs octets restaient inchangés. Dix fichiers de test malformés ou incohérents ont été rejetés. L'exemple de sérialisation a également produit les résultats documentés de 5 et 9 octets. Ces contrôles valident les exemples ; aucun client Metin2 n'a été compilé, modifié ou lancé, et aucune performance en jeu n'est revendiquée.

Pour un autre projet, commencez par sa compilation actuelle et ses propres prérequis ; l'annuaire des serveurs privés Metin2 aide à trouver son profil. Si le client échoue pendant l'initialisation graphique, le guide No Appropriate Device traite ce symptôme différent.

• Microsoft : LAA et espace d'adressage de 4 Go, limites mémoire selon Windows, format PE/COFF, portage des jeux en 64 bits.
• Python : formats binaires standard et alignement.
• Turkmmo : question sur la migration d'une base nommée et Reddit : réponses de l'auteur sur la provenance du client.
• EterNext : sa propre annonce de migration.

Sources vérifiées le 5 novembre 2026. Les déclarations des sources, les métadonnées d'un exécutable et les tests en jeu restent des preuves distinctes.