Prever Windows 11 ARM64 para aplicações Delphi desde o início

Windows 11 ARM64 já não é no dia-a-dia B2B apenas um caso especial para entusiastas de tecnologia. Novas gerações de notebooks, autonomias de bateria mais longas, cenários “sempre ligados” e o desejo crescente por postos de trabalho leves e móveis fazem com que empresas comprem clientes ARM64 – por vezes deliberadamente, por vezes de forma incidental através de modelos padrão em contratos-quadro. Para equipas com software individualizado consolidado, isso é uma mensagem clara: ARM64 deve entrar cedo no planeamento técnico, caso contrário transformar-se-á mais tarde num projeto de adaptação dispendioso.

Em aplicações Delphi, a pergunta central raramente é “consegue Delphi compilar isto?”. Na prática, rollouts ARM64 falham quase sempre na periferia: DLLs nativas, componentes de impressão/scan, drivers de BD, engines de relatórios, integrações COM, rotinas de setup, code-signing ou pipelines de build que implicitamente conhecem apenas x64. Exatamente por isso vale a pena tratar Windows 11 ARM64 como um requisito de arquitetura e operação – não como um mero feature de plataforma.

Este artigo mostra quais os obstáculos técnicos típicos em Delphi, como identificar os riscos de forma sistemática e que caminhos de migração pragmáticos se têm revelado eficientes – desde preparar gradualmente módulos individuais até uma arquitetura-alvo clara com serviços e servidores REST.

Por que Windows 11 ARM64 é agora um tema de arquitetura

Em muitas empresas, “Windows” foi durante muito tempo sinónimo de x86/x64. Essa premissa está enraizada em scripts, instaladores, componentes de terceiros e por vezes até no modelo de dados (ex.: caminhos, chaves de registo, interfaces de drivers). Assim que surgem clientes ARM64, torna-se visível quanto conhecimento implícito existe no sistema. E esse é exatamente o ponto económico: adaptações tardias não são apenas “uns flags do compilador”, mas um trabalho de limpar premissas que se consolidaram ao longo de anos.

Na prática, ARM64 torna-se relevante sobretudo em três situações:

• Software cliente com longa duração de vida: aplicações de domínio usadas por 8–15 anos e ampliadas iterativamente. Uma nova plataforma cliente a meio do ciclo de vida é mais provável do que uma reconstrução completa.
• Frotas mistas: equipas de fora/serviço, notebooks de gestão, cenários com BYOD, ou subsidiárias que adquirem hardware diferente.
• Pressão de segurança e compliance: code-signing moderno, hardening, princípio do menor privilégio, atualizadores controlados – nestes contextos instala-se e toca-se já aos processos de instalação e atualização. É precisamente aí que ARM64 é vantajoso como requisito secundário a integrar.

A boa notícia: quem já trabalha em Delphi Modernisierung, migração para 64-bit, desacoplamento de acessos a dados ou numa arquitetura-alvo orientada a serviços, consegue frequentemente “levar” Windows 11 ARM64 consigo – desde que esteja cedo no backlog e não apenas quando surge a primeira máquina ARM no suporte.

Delphi em ARM64: o que é “fácil”, o que é “difícil”?

Os projetos Delphi variam muito: desde clientes desktop VCL puros até sistemas multicamada com REST-Server, serviços Windows, workers de relatório, componentes de integração e jobs em segundo plano. Para Windows 11 ARM64 é decisivo que partes têm realmente de correr nativamente no cliente e que partes podem, de forma sensata, ser externalizadas para serviços.

O compilador raramente é o principal problema

Se o código próprio estiver limpo (sem assembler inline, sem pressupostos antigos de 32-bit, sem casts de ponteiro frágeis, sem chamadas API obsoletas), compilar para uma nova plataforma-alvo é frequentemente viável. Os problemas surgem por:

• Componentes de terceiros com partes nativas (DLLs, BPLs, pontes C/C++)
• Drivers e ligação a dispositivos (impressão, scan, pads de assinatura, dongles)
• Acesso a bases de dados via ODBC/OLE DB/client-libraries que não suportam ARM64
• Reporting e integração Office (automação COM, filtros de exportação antigos)
• Installer/Updater que só testam x64 ou usam caminhos codificados

Portanto, Windows 11 ARM64 é sobretudo um “teste do ecossistema”: quão bem o seu pacote de software está desacoplado de pressupostos antigos de plataforma?

VCL, FMX e dependências de UI

Muitas aplicações B2B de domínio são baseadas em VCL e usam componentes UI acumulados ao longo de anos. Isso não é em si um problema – mas a UI costuma ser onde as dependências se concentram: impressoras PDF, geradores de códigos de barras, bibliotecas de imagens, controles de browser, objetos COM. Para Windows 11 ARM64 vale a regra: quanto mais componentes especializados ligados à UI usar, mais importante se torna uma lista de compatibilidades precoce.

Em estratégias multiplataforma (ex.: Windows + macOS) costuma entrar FMX. Independentemente do framework, uma estratégia robusta é separar a lógica de domínio e as integrações da UI. Isso beneficia tanto Delphi Multiplattform como Windows 11 ARM64.

Obstáculos técnicos típicos (e como os identificar cedo)

Na prática, a maioria dos problemas ARM64 pode ser detectada cedo se inventariar de forma estruturada e realizar um “ARM64 Readiness”-Check. É crucial não olhar só para o código Delphi, mas para tudo o que pertence ao produto: instalador, drivers, configuração, plugins, ferramentas de terceiros, cadeia de atualização, scripts de suporte.

1) DLLs nativas, BPLs e paisagens de processos mistos

Muitas aplicações Delphi carregam DLLs adicionais: criptografia, visualizadores CAD, OCR, assinatura, SDKs de hardware, parsers especializados. Em x64 costuma assumir-se tacitamente que “há uma DLL 64-bit”. Para ARM64 é diferente: precisa de binários ARM64 explícitos ou de uma arquitetura que retire essa dependência do cliente.

Abordagem prática:

• Liste todos os módulos nativos carregados (incluindo indiretos via componentes).
• Classifique: “ARM64 disponível”, “x64-only”, “32-bit-only”, “incerto”.
• Avalie se o módulo tem de ser local ou se pode ser oferecido como serviço.

Um achado comum: um único módulo x64-only bloqueia o cliente ARM64 inteiro. É nesse momento que uma camada de arquitetura limpa ou uma Layer-3 Architektur se justifica economicamente: a UI/cliente permanece leve, integrações migram para camadas de servidor/serviço controladas.

2) COM, automação Office e integrações com o Shell

Em muitas empresas, exportação para Word/Excel, ligação ao Outlook, menus de contexto do Explorer ou integrações DMS cresceram historicamente via COM. COM não é automaticamente “ARM64-ready”, sobretudo se servidores COM de terceiros ou add-ins só existirem em x64. Também a operação em misturas 32-bit/64-bit (Out-of-Proc vs. In-Proc) torna-se rapidamente complexa.

Esclarecimentos a fazer cedo:

• Que objetos COM são usados (lista de ProgIDs/CLSIDs)?
• In-Proc ou Out-of-Proc? Existem registos ARM64?
• É possível substituir a exportação por bibliotecas server-side (ex.: formatos baseados em documentos) em vez de automação Office?

Frequentemente isto é uma alavanca de modernização: sair da automação ligada à UI e migrar para serviços de exportação reproduzíveis (ex.: PDF/Excel via bibliotecas), utilizáveis tanto em Windows x64 como em ARM64 ou até em servidores Linux.

3) Acesso a bases de dados: ODBC, client-libraries, legados BDE

O acesso a dados é uma interface frequente para ARM64, porque aqui entram drivers e client-libraries. Particularmente críticos são setups ODBC antigos, clientes proprietários de BD ou bases locais com camadas de acesso históricas.

Para stacks Delphi isto é clássico: se ainda existem BDE, estruturas Paradox antigas ou cadeias de drivers difíceis de manter, ARM64 atua como catalisador. Uma substituição de BDE e a migração para uma BDE-Ablösung com ligação nativa e uma estratégia clara de drivers de BD reduzem muito os riscos de plataforma.

Pontos de verificação concretos:

• Quais DBs estão em uso (SQL Server, PostgreSQL, MariaDB, Firebird, engines locais)?
• Que drivers são usados (ODBC, cliente nativo, drivers BDE-Ablosung mit nativer Anbindung, OLE DB)?
• Onde estão connection-strings e DSNs (por utilizador, por máquina, no instalador)?
• Existem dependências em drivers ODBC 32-bit ou providers antigos?

Em particular com SQL Server/ODBC, um cliente ARM64 pode funcionar – desde que a cadeia de drivers e a rotina de instalação estejam limpas. Não é algo que se queira depurar “em produção”.

4) Reporting, impressão, scan, PDF e fluxos de output

O output é frequentemente negócio-crítico em aplicações de domínio: guias de entrega, etiquetas, faturas, relatórios, leituras de contadores, certificados, etiquetas de envio. Muitos desses fluxos dependem de componentes de reporting ou de drivers específicos de impressora/scan.

Em Windows 11 ARM64 os obstáculos típicos são:

• Drivers de impressoras de etiquetas/especiais disponíveis apenas em x64
• Software/SDKs de scanner sem suporte ARM64
• Engines de relatório antigos com módulos nativos de preview/export
• Geração de PDF via “impressoras virtuais” em vez de bibliotecas

Um caminho robusto é padronizar os fluxos de output: gerar PDF/formatos Office via bibliotecas, impressão através de interfaces standard, encapsular o acesso a hardware específico sempre que possível. Onde isso não for viável, é necessária cedo uma matriz de dispositivos/drivers para ARM64.

5) Installer, updater, code-signing e operação

Muitos projetos ARM64 não falham pelo programa em si, mas pela entrega: o setup detecta a arquitetura errada, não instala drivers, não regista COM, define caminhos incorretos ou esbarra em políticas de code-signing. Atualizadores automáticos (delta-updates, self-updaters) também costumam ser fortemente dependentes de arquitetura.

Perguntas importantes para a operação:

• Como se instala (MSI, Inno Setup, updater próprio)?
• Como são instaladas as dependências (VC++ Runtimes, drivers, certificados)?
• Como é feito o signing (EXE, DLL, instalador, pacotes de driver)?
• Como se testa: hardware ARM64 real ou apenas pressuposições?

Para empresas isto é uma questão de governação: quando Windows 11 ARM64 aparece na frota cliente, o deployment tem de ser reproduzível – incluindo rollback, possibilidade de suporte e versãoção clara.

Estratégia: tratar Windows 11 ARM64 como um “requisito não funcional” precoce

A abordagem economicamente sensata é tratar ARM64 como um requisito não-funcional (NFA) – tal como performance, segurança ou capacidade offline. Isso significa: não só quando “queima” no sprint, mas como uma orientação definida para arquitetura e cadeia de fornecimento.

ARM64-Readiness-Check: inventário em vez de feeling

Um check sólido abrange tipicamente:

• Inventário de dependências: todos os componentes de terceiros, DLLs, drivers, SDKs, controles de browser, módulos criptográficos, reporting.
• Análise de build/pipeline: targets de build, empacotamento, signing, armazenamento de artefactos, versionamento, reprodutibilidade.
• Cadeia de installer/update: lógica de setup, pré-requisitos, chaves/paths do registo/sistema de ficheiros, políticas, permissões.
• Modelo de operação: suporte, logging, crash-dumps, telemetria (se existente), plano de rollout.

O resultado não deve ser apenas “ARM64: sim/não”, mas uma lista priorizada: que bloqueadores existem, que módulos são afetados, que alternativas existem e que investimento é realista.

Matriz de decisão: nativo em ARM64 ou desacoplar?

Para cada dependência problemática convém decidir claramente:

• Substituto nativo ARM64 possível: atualizar, mudar de fornecedor, migrar para outra biblioteca.
• A dependência pode ser externalizada: por ex., para um serviço [[NBML_TERM_5_aea23489 ]], um worker em background ou um servidor REST-Server.
• A dependência tem de permanecer local: por ex., porque o hardware está ligado diretamente ao cliente. Nesse caso são necessárias autorizações firmes de hardware/driver para ARM64.

Para integrações, externalizar é muitas vezes a opção mais limpa: o cliente permanece UI + diálogos de domínio, enquanto lógica de integração complexa corre em serviços controlados. Isso favorece além de ARM64 também updates centralizados, modelos de privilégios e melhor testabilidade.

Patterns de arquitetura que tornam projetos ARM64 estáveis

Se Windows 11 ARM64 for planeado cedo, várias decisões arquiteturais podem ser tomadas de forma a evitar revisões dispendiosas mais tarde.

1) Camadas claras: UI, lógica de domínio, integração, acesso a dados

Clients Delphi evoluídos costumam ter “tudo num processo”: UI, regras de negócio, acesso a dados, ligação a DMS, impressão e exportação. Isso é sustentável enquanto a plataforma for estável. Quando variantes de plataforma (ARM64, possivelmente [[NBML_TERM_8_8b06df02 ]], possivelmente servidores de terminais) se tornam relevantes, o valor de uma clara separação em camadas sobe.

Imagem alvo pragmática:

• Camada UI: mínima, testável, sem dependências diretas a drivers/SDKs.
• Logica de domínio: o mais neutra possível quanto à plataforma, modelada com clareza.
• Camada de integração: encapsula COM, formatos de ficheiro, conectores DMS/ERP, SDKs de dispositivos.
• Acesso a dados: consolidado (ex.: FireDAC), com fronteiras de transação claras, sem SQL espalhado.

Isto não é “académico”, mas reduz custos reais mais tarde: se só a camada de integração é problemática para ARM64, não é preciso reconstruir todo o cliente.

2) Serviços e servidores REST como âncora de estabilidade

Muitos sistemas B2B beneficiam de funções centrais a correr como REST-Server ou como serviços Windows/ Linux-Services: verificação de privilégios, workflows de documentos, validação de dados, exportação/importação, interfaces a ERP/DMS/CRM. Quando estas funções correm server-side, a complexidade no cliente reduz-se consideravelmente – e com ela a superfície de ataque ARM64.

Divisões típicas e eficazes:

• Cliente: diálogos, apresentação, lógica offline (se necessário), integrações locais mínimas.
• REST-Server: operações de domínio, validação, multi-tenancy, logging central.
• Worker/Service: jobs agendados, polling de interfaces, geração de relatórios, exports batch.

Isto também se alinha com modelos modernos de operação: uma função server-side é atualizada uma vez – em vez de em cada cliente ARM64 individual.

3) Um sistema de build com vários targets (x64 + ARM64) desde o início

Se ARM64 é um objetivo, a pipeline de build deve refletir isso. Não como “um build especial mais tarde”, mas como padrão: cada versão candidata a release compila de forma reproduzível para x64 (e, se previsto, ARM64), incluindo signing e empacotamento do instalador.

O importante é menos a ferramenta e mais a consistência:

• Nomear artefactos de forma clara (a arquitetura no nome do pacote/estrutura de pastas).
• Separar valores de configuração por target (caminhos, prerequisites, pacotes de driver).
• Definir smoke-tests por arquitetura (arranque, login, ligação BD, impressão/PDF).

Assim ARM64 deixa de ser um “Big Bang” e torna-se um target adicional controlado.

Modernização Delphi: ARM64 como oportunidade para reduzir dívida técnica

Muitas empresas usam novos requisitos de plataforma como pretexto para “fazer tudo de novo”. Isso é arriscado e muitas vezes desnecessário. Mais económico é usar Windows 11 ARM64 como guia para uma modernização faseada: eliminar dívida técnica onde ela bloqueia ARM64 ou põe em risco a capacidade de entrega.

64-bit e Unicode: não adiar problemas antigos

Se a base de código ainda contém pressupostos de 32-bit ou resíduos de versões antigas [[NBML_TERM_7_4c4a218d ]], esses problemas reaparecerão na mudança de plataforma. Mesmo que ARM64 não signifique automaticamente “Unicode”, muitos projetos que encaram ARM64 a sério aproveitam para garantir ao mesmo tempo suporte sólido a Unicode, caminhos 64-bit e limpeza de questões de memória/ponteiros.

O objetivo não é perfeição, mas um padrão fiável: código que possa ser construído para novos targets sem reproduzir constantemente as mesmas classes de erro.

Substituição de BDE e acesso a dados consolidado como facilitador ARM64

Onde persistem camadas de acesso históricas ([[NBML_TERM_11_901e2bf2 ]], dados Paradox locais, acessos mistos), a consolidação é uma alavanca com efeitos múltiplos: código mais manutenível, deployments mais estáveis, estratégia de drivers mais clara. Com FireDAC é possível uniformizar o acesso em muitos cenários, incluindo gestão central de parâmetros, estratégias de pooling e tratamento de erros consistente.

Importante: a substituição de BDE não é só “trocar componentes”. Afeta lógica transacional, tipos de dados, ordenações, semântica de filtros e por vezes o modelo de dados. Por isso deve ser planeada – não deixada como medida de emergência quando clientes ARM64 surgem inesperadamente no campo.

Teste e QA: ARM64 só é planear se for mensurável

Planejar ARM64 precocemente significa também: tem de ser testado – não como teste exaustivo de todas as funcionalidades, mas como teste de risco focado na cadeia crítica. O passo mais importante é ter um ambiente de teste ARM64 real. Emulação pode ajudar em casos pontuais, mas não substitui a prática com hardware real, drivers reais e políticas de segurança reais.

Smoke-test ARM64 mínimo: o que deve ser coberto cedo

Um conjunto pragmático e eficaz de smoke-tests para cada versão candidata à release:

• Arranque do programa, login, funções UI básicas
• Ligação à BD (incluindo autenticação, certificados, DNS/Proxy, se relevante)
• Um processo central “end-to-end” (ex.: criar pedido, gravar, imprimir/exportar)
• Updater/Installer: instalação nova e atualização entre versões
• Logging/diálogos de erro: os diagnósticos são úteis também em ARM64?

Com isto os bloqueadores típicos ARM64 tornam-se visíveis cedo: DLLs ausentes, drivers errados, problemas de setup, exigências de privilégios inesperadas.

Capacidade de diagnóstico: crash-dumps, logs, transparência de versões

Quando ARM64 está na frota, irão surgir casos de suporte – só pela mera diversidade de drivers. Por isso compensa padronizar diagnósticos: IDs de build claras, logs significativos, caminhos de instalação/atualização reproduzíveis. Isso não é específico de ARM64, mas ARM64 torna deficiências nesses aspetos rapidamente caras.

Rollout e operação: frotas mistas sem caos

A maioria das empresas operará a médio prazo frotas mistas: parte x64, parte ARM64. A chave é gerir esse estado de forma deliberada.

Empacotamento: instaladores separados, deteção clara, vias de download inequívocas

Na prática funciona melhor quando instaladores/pacotes são inequívocos: o pacote x64 é x64, o pacote ARM64 é ARM64. “Um instalador para tudo” soa prático, mas rapidamente complica (lógica de verificação, prerequisites, paths de drivers, signing, reparação de instalação). Para rollouts empresariais controlados, a clareza costuma ser a opção mais robusta.

Estratégia de atualização: sem caminhos especiais para ARM64

ARM64 não deve ser um caso especial no processo de atualização. Objetivo: mesma frequência de releases, mesma numeração de versão funcional, mas artefactos separados. Se ARM64 for atualizado apenas “manualmente”, geram-se divergências na frota que elevam os custos de suporte.

Documentar integrações de forma consistente

Muitos problemas ARM64 não estão no código próprio, mas nas integrações: conector ERP, cliente DMS, serviço de assinatura, software de scanner, impressora de etiquetas. Uma lista de integrações bem mantida com versões e notas de arquitetura é útil em B2B de qualquer forma – e torna as decisões sobre ARM64 transparentes.

O que as empresas devem fazer agora (sem ativismo)

Planear Windows 11 ARM64 cedo não significa reestruturar tudo imediatamente. Significa responder às perguntas certas desde cedo e eliminar bloqueadores enquanto o esforço é previsível. Um procedimento comprovado é:

• 1) Levantamento (2–10 dias dependendo do tamanho do sistema): dependências, instalador, drivers, acesso a dados, COM, reporting.
• 2) Imagem alvo e caminho: o que tem de correr nativamente no cliente? O que será serviço/REST? Que componentes serão substituídos?
• 3) Prova de viabilidade: um build ARM64 funcional com instalador e um caso de uso end-to-end.
• 4) Endurecimento faseado: restantes funções, testes, cadeia de atualização, capacidade de diagnóstico.

Assim não surge um “projeto ARM64” isolado a correr meses, mas sim uma extensão controlada da capacidade de entrega.

Conclusão: Windows 11 ARM64 não é um hype, mas um indicador precoce de maturidade técnica

Windows 11 ARM64 tornará-se realidade para muitas empresas – por compras de hardware, requisitos de mobilidade ou normalização. Para aplicações Delphi o desafio real não é só o código-fonte, mas o sistema completo de dependências, processos de instalação/atualização, integrações e drivers. Quem planear ARM64 cedo pode esclarecer esses pontos de forma estruturada, em vez de os “corrigir” mais tarde sob pressão de tempo.

No fim das contas, ARM64 é um teste útil: quão bem desacoplada, testável e entregue é a sua aplicação? Se responder a essa pergunta agora, ganha não só opções de plataforma, mas também uma base mais estável para modernização, serviços, arquiteturas REST e manutenção a longo prazo.

Contacte Net-Base Software GmbH, se quiser avaliar de forma fiável Windows 11 ARM64 na sua roadmap Delphi e implementá‑la com um caminho técnico claro.