Diferenças entre Windows e Linux

O contrato do Client Conecta é idêntico no Windows e no Linux: mesma função exportada, mesmos pacotes JSON, mesmos campos e mesmos códigos de retorno. O que muda é o entorno: carga da biblioteca, toolkit gráfico e porta do pin pad. Esta página reúne essas diferenças.

Para o contrato geral e o primeiro exemplo de venda, consulte o Guia de integração.

A tabela a seguir compara os aspectos que mudam entre as plataformas.

AspectoWindowsLinux
Artefatoclientconecta.dllclientconecta.so
Carga e descargaLoadLibrary, GetProcAddress e FreeLibrarydlopen(RTLD_NOW | RTLD_LOCAL), dlsym e nunca dlclose
Instâncias simultâneasVáriasUma por usuário. A segunda instância termina na carga.
Encerramento da ACFluxo normal_exit(). exit() e o retorno de main quebram.
Runtime necessárioVCRUNTIME140.dll / UCRTglibc 2.25 ou superior e pacote ca-certificates
Toolkit gráficoMFC, WinForms e WPFMFC não existe: use wxWidgets, GTK ou Qt. Exige servidor X11 ou Wayland.
Porta do PINPADPortPinpad de 1 a 99 vira COM<n>Deixe vazio (automático).
Permissão do dispositivoNão se aplicaUsuário no grupo dialout
Sistema de arquivosNão diferencia maiúsculas de minúsculas, usa \ e CRLFDiferencia maiúsculas de minúsculas, usa / e LF
Integridade do artefatoAssinatura Authenticode verificávelSem equivalente. Resolva no processo de distribuição (hash ou GPG do pacote).

A arquitetura da AC precisa casar com a da biblioteca: um processo x64 não carrega uma biblioteca x86, e vice-versa.

Particularidades do Linux

PortPinpad no Linux

O valor numérico de PortPinpad é convertido para "COM<n>" nas duas plataformas, porque esse é código comum. No Linux, isso não corresponde a nenhum dispositivo real. A descoberta automática da porta (/dev/ttyACM* e /dev/ttyUSB*) só acontece quando o valor final é literalmente "automático".

Regra: no Linux, omita PortPinpad do pacote ou envie o campo vazio.

Namespace de símbolos no Linux

No Linux, a biblioteca exporta milhares de símbolos globais, incluindo os das bibliotecas de terceiros que traz ligadas estaticamente (OpenSSL, SQLite e jansson). Carregue sempre com dlopen(caminho, RTLD_NOW | RTLD_LOCAL) e nunca use RTLD_GLOBAL.

Com RTLD_GLOBAL, os símbolos internos seriam publicados no namespace global do processo. Se a AC também usar OpenSSL, SQLite ou jansson, ela pode se ligar à cópia interna da biblioteca em vez de à sua própria, com corrupção silenciosa.

Carga e descarga no Linux

No Linux, a biblioteca tem construtor e destrutor próprios, executados automaticamente pelo carregador dinâmico: o código roda antes da primeira chamada da AC (no dlopen) e depois da última.

  • Ao carregar: a biblioteca trava um arquivo de lock exclusivo por usuário. Se a trava já estiver em uso (segunda instância ou segunda janela do mesmo aplicativo), o processo da AC termina imediatamente. Não é um dlopen que retorna NULL e pode ser tratado: é o processo inteiro saindo. Capture o stderr do processo, porque a falha aparece nele antes de qualquer log da aplicação;
  • Ao descarregar: o dlclose dispara o desligamento interno da biblioteca, que pode quebrar o processo se threads internas de rede ainda estiverem ativas. Nunca chame dlclose em uma aplicação que já tenha inicializado a sessão (001). Nunca encerre com exit() nem retornando de main, porque os dois caem no mesmo caminho do dlclose. Encerre sempre com _exit() ou _Exit(), a partir de um único ponto de saída (menu Sair, botão, X da janela, Ctrl+C ou sinal, todos convergindo para o mesmo tratador).

Esse comportamento é específico do Linux. No Windows, o FreeLibrary tem sequência própria de encerramento no DllMain. Não replique o _exit no Windows.

Diretório de trabalho no Linux

A biblioteca grava arquivos (logs, banco local e recibos) com caminho relativo ao diretório de trabalho do processo. No Linux, lançadores de desktop e serviços tendem a herdar outro diretório, e uma sessão inicializada antes "desaparece". Fixe o diretório de trabalho na pasta da aplicação antes do INITIALIZE, conforme descrito no Guia de integração.


Did this page help you?