Metin2 de 32 ou 64 bits: verificar o EXE e a opção de 4 GB

Um cliente Metin2 pode continuar a ser um programa x86 de 32 bits mesmo quando funciona no Windows de 64 bits e tem a opção Large Address Aware ativada. Essa opção, frequentemente associada a um «patch de 4 GB», diz respeito ao espaço de endereçamento. Um cliente x64 nativo é uma compilação diferente, com outra arquitetura de máquina. Nenhuma destas designações, por si só, comprova mais FPS ou uma solução para todos os encerramentos inesperados.

A primeira pergunta útil é: qual é a arquitetura do executável que realmente executa o jogo? Os requisitos de Windows de um servidor, o seu launcher e o processo do jogo podem referir-se a componentes diferentes. Este guia explica uma verificação do cabeçalho EXE apenas de leitura e os limites do resultado. Não pressupõe que todos os servidores Metin2 distribuam o mesmo cliente.

Ilustração gerada com referências do jogo Metin2. Não é uma captura de ecrã, uma medição de memória ou prova de uma compilação específica do cliente.

A documentação da Microsoft sobre LAA e as tabelas de limites de memória distinguem o espaço de endereçamento virtual de um processo da RAM física instalada. As linhas sobre limites de memória abaixo pressupõem uma edição x64 do Windows. A linha ARM64 identifica outra arquitetura de ficheiro; não afirma que esse ficheiro funciona no Windows x64.

Estes são limites de espaço de endereçamento. Não garantem que o cliente consiga reservar um único bloco contíguo de 4 GB, utilizar toda a RAM ou evitar qualquer falha de alocação. Um executável x64 nativo com LAA desativada também tem restrições adicionais; não deduzas o seu limite efetivo apenas da expressão «64 bits».

Do mesmo modo, ter 32 GB de RAM física não elimina o limite de endereçamento de um processo x86. Aumentar esse limite só ajuda em problemas que realmente dependam dele. Um recurso corrompido, um ponteiro inválido ou um módulo incompatível exige o seu próprio diagnóstico.

Na discussão do Turkmmo de maio de 2026, o autor identifica uma base MartySama v5.8 e relata que compilar o servidor em 64 bits foi mais fácil do que portar o cliente. As respostas abordam a manutenção de distribuições x86 e x64 em paralelo e a preservação da compatibilidade dos pacotes. São relatos sobre o conjunto de código-fonte desse autor, não um procedimento de migração testado para outro servidor.

Uma discussão independente no Reddit sobre um servidor Linux e um cliente x64 ilustra outra ambiguidade: quando lhe perguntam se foi ele a portar o cliente, o autor responde que o obteve de outra pessoa. Uma captura de ecrã ou o facto de um servidor ter sido adaptado não identifica a origem, a revisão ou a arquitetura de todos os componentes.

O diário de desenvolvimento da EterNext de 1 de abril de 2026 anuncia um cliente nativo de 64 bits para esse projeto específico. Não inspecionámos o seu executável atual nem reproduzimos as alegações de desempenho. Trata uma declaração datada do operador como informação sobre aquele projeto; verifica a compilação real antes de a aplicar a outro cliente.

Primeiro, identifica o executável que inicia o jogo. O patcher, o atualizador e a ferramenta de configuração podem ser ficheiros separados com arquiteturas diferentes. Consulta a documentação do operador ou o nome do processo do jogo no Gestor de Tarefas; não pressuponhas que todos os clientes privados usam o mesmo nome de ficheiro.

A especificação PE/COFF da Microsoft define o campo Machine, o formato do cabeçalho opcional e a opção IMAGE_FILE_LARGE_ADDRESS_AWARE. O leitor Python 3 abaixo utiliza apenas a biblioteca padrão e abre o ficheiro escolhido em modo de leitura binária. Guarda-o como pe_info.py e executa python pe_info.py client.exe, substituindo o último nome pelo executável que identificaste.

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

Interpreta os campos em conjunto. Machine:0x014C, Format:PE32, LAA:true significa um executável x86 marcado como large-address-aware, não um executável x64 nativo. Machine:0x8664 com PE32+ identifica AMD64; 0xAA64 identifica ARM64. Estas designações são definidas pela especificação da Microsoft, não deduzidas do nome do ficheiro.

O leitor verifica as assinaturas DOS/PE, os limites dos cabeçalhos e os três pares Machine/Magic suportados. É um pequeno inspetor de metadados, não uma validação completa do carregamento PE, um verificador de assinaturas ou uma avaliação da segurança de executar o ficheiro. Um cabeçalho não suportado ou incoerente é motivo para parar de interpretar o resultado, não uma instrução para reparar o EXE. O script não modifica cabeçalhos nem executa o ficheiro.

As orientações da Microsoft para portar jogos identificam o truncamento de ponteiros, o alinhamento, os formatos binários persistidos e as bibliotecas de terceiros como pontos de atenção. As DLLs nativas comuns carregadas dentro de um processo têm de corresponder à sua arquitetura; mudar o nome de uma DLL x86 não a transforma numa dependência x64.

Numa árvore de código-fonte Metin2, revê o código que guarda ponteiros ou comprimentos em inteiros mais estreitos, a fronteira entre Python e código nativo, os descodificadores de recursos e as bibliotecas utilizadas naquela revisão exata. Depois, compila as dependências correspondentes. O trabalho concreto depende do projeto; esta lista não é um patch instalável para um pacote de código-fonte não identificado.

Separa a arquitetura dos resultados de desempenho. Compara a mesma revisão do cliente, os mesmos recursos, a mesma cena e as mesmas definições, registando as condições das falhas relacionadas com memória e os tempos por fotograma. A Microsoft recomenda voltar a analisar o desempenho após a adaptação. Não medimos qualquer aumento de FPS numa compilação x64 de Metin2 para este artigo.

A rede transmite bytes, não a designação da CPU do cliente. Um cliente de 32 bits e um servidor de 64 bits podem comunicar se o protocolo real continuar compatível. Saber se isso acontece num par Metin2 específico exige as respetivas definições de pacotes e testes; nomes iguais ou uma compilação bem-sucedida não comprovam a compatibilidade.

Este exemplo ilustra um formato de bytes; não é a definição de um pacote Metin2:

import struct

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

O resultado é <BI 5 01e8030000 e <BQ 9 01e803000000000000. Segundo a documentação de struct do Python, < especifica little-endian, tamanhos padrão e ausência de preenchimento de alinhamento; I ocupa 4 bytes e Q ocupa 8. Só o alargamento desse campo muda a mensagem de 5 para 9 bytes. Um destinatário que espera o formato antigo precisa de uma alteração acordada do protocolo, não da suposição de que a nova arquitetura da CPU resolverá a diferença.

A mesma revisão aplica-se aos dados binários guardados e aos formatos de recursos. Preserva contratos explícitos de transmissão e de ficheiros, ou introduz versões deliberadamente e testa ambos os lados. Não substituas mecanicamente todos os inteiros de 32 bits por um tipo do tamanho de um ponteiro: identificadores do jogo, contadores, comprimentos e ponteiros têm funções diferentes.

Para os jogadores, a verificação do cabeçalho distingue a arquitetura do ficheiro fornecido de uma indicação no launcher ou dos requisitos do Windows. Usa a distribuição suportada pelo servidor e pergunta ao operador qual é a compilação do jogo que inclui. O resultado não comprova início de sessão, entrada no mundo, estabilidade ou compatibilidade com a proteção desse servidor.

Para os operadores, conserva uma compilação que sabes funcionar enquanto revês o código-fonte e as dependências que realmente te pertencem ou que estás autorizado a utilizar. Código publicamente legível, uma ligação para download e uma licença de código aberto são factos diferentes. Este artigo não recomenda um pacote de código-fonte não verificado como cliente de 64 bits pronto a usar.

Executámos o leitor em quatro exemplos sintéticos de cabeçalhos e em dois executáveis existentes do Windows, verificando que os respetivos bytes ficaram inalterados. Foram rejeitados dez exemplos malformados ou incoerentes. O exemplo de serialização também produziu os resultados documentados de 5/9 bytes. Estas verificações validam os exemplos; nenhum cliente Metin2 foi compilado, modificado ou iniciado, e não apresentamos qualquer resultado de desempenho do jogo.

Para outro projeto, começa pela sua compilação atual e pelos seus requisitos. O diretório de servidores privados Metin2 ajuda a encontrar o perfil correspondente. Se o cliente falha durante a inicialização gráfica, o guia separado sobre No Appropriate Device aborda esse sintoma diferente.

• Microsoft: LAA e espaço de endereçamento de 4 GB, limites de memória por versão do Windows, formato PE/COFF, portar jogos para 64 bits.
• Python: formatos binários padrão e alinhamento.
• Turkmmo: questão de migração com a base de código identificada e Reddit: respostas do autor sobre a origem do cliente.
• EterNext: anúncio da sua própria migração.

Fontes consultadas em 5 de novembro de 2026. Declarações das fontes, metadados dos executáveis e jogabilidade testada continuam a ser provas distintas.