Planificar amb antelació Windows 11 ARM64 per a aplicacions Delphi

Windows 11 ARM64 ja no és en l’àmbit B2B només un cas especial per a entusiastes de la tecnologia. Noves generacions de portàtils, autonomies més llargues, escenaris „Always-on“ i el creixent desig de llocs de treball lleugers i mòbils fan que les empreses comprin clients ARM64 – de vegades de manera conscient, altres vegades com a part dels models estàndard en contractes marc. Per a equips amb software empresarial personalitzat, això és un missatge clar: ARM64 ha d’estar present aviat en la planificació tècnica, si no després es convertirà en un projecte de millora costós.

En aplicacions Delphi la pregunta central rarament és «pot Delphi compilar això?». A la pràctica, els desplegaments ARM64 fallen gairebé sempre a la perifèria: DLLs natives, components d’impressió/escaneig, controladors de base de dades, engines de reporting, integracions COM, rutines d’instal·lació, signatura de codi o pipelines de build que silenciosament només coneguin x64. Precisament per això val la pena tractar Windows 11 ARM64 com un requisit d’arquitectura i d’operació – no com una mera funció de plataforma.

Aquest article mostra quins entrebancs tècnics apareixen habitualment en Delphi, com identificar sistemàticament els riscos i quins camins de migració pragmàtics han demostrat ser útils – des de preparar pas a pas mòduls individuals fins a una arquitectura objectiu clara amb serveis i REST-servers.

Per què Windows 11 ARM64 ara és un tema d’arquitectura

En moltes empreses «Windows» durant molt de temps ha estat sinònim d’x86/x64. Aquesta assumpció està incrustada en scripts, instal·ladors, components de tercers i fins i tot a vegades en el model de dades (p. ex. rutes, claus del registre, interfícies de controladors). Quan apareixen clients ARM64, es fa visible la quantitat de coneixement implícit que hi ha al sistema. I aquest és el nucli econòmic: les adaptacions tardanes no són només «unes quantes opcions del compilador», sinó netejar assumptes que s’han anat consolidant durant anys.

ARM64 esdevé pràcticament rellevant especialment en tres situacions:

• Software client amb llarga vida útil: aplicacions sectorials que s’utilitzen durant 8–15 anys i s’amplien de manera iterativa. Una nova plataforma client a mitjan cicle de vida és més probable que una reconstrucció completa.
• Flotes mixtes: servei extern/atenció tècnica, portàtils de direcció, escenaris propers a BYOD o filials que adquireixen diferent maquinari.
• Pressió de seguretat i compliment: signatura de codi moderna, hardening, «least privilege», actualitzadors controlats – en aquests processos d’instal·lació i actualització ja s’intervé. Precisament llavors és fàcil integrar ARM64 com a requisit addicional.

La bona notícia: qui ja treballa en Delphi Modernisierung, migració a 64 bits, desacoblament dels accessos a dades o en una arquitectura objectiu orientada a serveis, sovint pot fer que Windows 11 ARM64 «vagi acompanyant» – sempre que estigui aviat en el backlog i no només aparegui com a problema en la primera màquina ARM que arriba al suport.

Delphi en ARM64: què és «fàcil», què és «difícil»?

Els projectes Delphi varien molt: des de clients d’escriptori VCL fins a sistemes multicapa amb REST-Servers, serveis Windows, workers de reporting, components d’integració i tasques en segon pla. Per a Windows 11 ARM64 és determinant quines parts realment han d’executar-se de manera nativa al client i quines parts ja seria raonable externalitzar a serveis.

El compilador rarament és el problema principal

Si el vostre codi és net (sense assembler inline, sense antigues assumpcions de 32 bits, sense casts de punters fràgils, sense crides d’API obsoletes), compilar per una nova plataforma sovint és factible. Els problemes venen de:

• Components de tercers amb parts natives (DLLs, BPLs, ponts C/C++)
• Controladors i connexió de dispositius (impressió, escaneig, pads de signatura, dongles)
• Accés a bases de dades via ODBC/OLE DB/llibreries client que no són compatibles amb ARM64
• Reporting i integració Office (COM-Automation, filtres d’exportació antics)
• Instal·ladors/actualitzadors que només proveen proves per x64 o utilitzen rutes codificades

Així, Windows 11 ARM64 és sobretot una «prova d’ecosistema»: com de ben desacoblat està el vostre paquet de software de les velles assumpcions de plataforma?

VCL, FMX i dependències d’UI

Moltíssimes aplicacions B2B són basades en VCL i utilitzen components d’interfície que han crescut al llarg dels anys. Això no és necessàriament un problema – però la UI sovint és el lloc on es concentren dependències: impressores PDF, generadors de codi de barres, biblioteques d’imatges, controls de navegador, objectes COM. Per a ARM64 val: com més components específics a la UI utilitzeu, més important és tenir una llista de compatibilitats aviat.

En estratègies multiplataforma (p. ex. Windows + macOS) entra sovint FMX. Independentment del framework, una estratègia robusta és separar la lògica de negoci i les integracions de la UI. Això beneficia tant Delphi Multiplattform com Windows 11 ARM64.

Entrebancks tècnics típics (i com detectar-los d’hora)

A la pràctica, la majoria de problemes ARM64 es poden detectar aviat si feu una inventarització estructurada i un „ARM64 Readiness“-check. És crític no mirar només el codi Delphi, sinó tot el que forma part del producte: instal·ladors, controladors, configuració, plugins, eines de tercers, cadena d’actualització, scripts de suport.

1) DLLs natives, BPLs i paisatges de processos mixtos

Moltíssimes aplicacions Delphi carreguen DLLs addicionals: criptografia, visualitzadors CAD, OCR, signatura, SDKs de maquinari, parsers especials. En x64 sovint s’assumeix tacitament que «ja existeix una DLL de 64 bits». Per a ARM64 això és diferent: necessiteu explícitament binaris ARM64 o una arquitectura que tregui aquesta dependència del client.

Enfocament pràctic:

• Compileu una llista de tots els mòduls natius carregats (incloent-hi els carregats indirectament per components).
• Classifiqueu-los: «ARM64 disponible», «només x64», «només 32-bit», «desconegut».
• Avalueu si el mòdul realment ha d’estar local o pot externalitzar-se com a servei.

Una troballa habitual: un sol mòdul x64-only bloqueja tot el client ARM64. Aquest és el moment en què una capa i una Layer-3 Architektur neta esdevé econòmicament justificable: la UI/client es manté lleugera i les integracions es desplacen a capes de servidor/servei controlades.

2) COM, Office-Automation i integracions amb l’entorn

A moltes empreses les exportacions a Word/Excel, la connexió amb Outlook, menús de context de l’Explorer o integracions DMS han crescut històricament via COM. COM no és automàticament «ARM64-ready», sobretot si servidors COM de tercers o add-ins només s’entreguen en x64. També el funcionament de barreges 32-bit/64-bit (Out-of-Proc vs. In-Proc) es complica ràpidament.

Clarificació precoç:

• Quins objectes COM s’estan utilitzant (llista de ProgIDs/CLSIDs)?
• In-Proc o Out-of-Proc? Existeixen registres ARM64?
• Es pot resoldre l’exportació amb biblioteques server-side (p. ex. formats basats en documents) en lloc d’Office-Automation?

Sovint això és una palanca de modernització: passar de l’automatització lligada a la UI cap a serveis d’exportació reproducibles (p. ex. PDF/Excel via biblioteca) que es poden utilitzar tant per Windows x64 com per ARM64 o fins i tot per Linux-servers.

3) Accés a base de dades: ODBC, llibreries client, legacy-BDE

L’accés a dades és una interfície crítica per ARM64 perquè aquí entren en joc paisatges de controladors i llibreries client. Són especialment crítics els antics entorns ODBC, clients propietaris de bases de dades o bases locals amb capes d’accés històriques.

Per als stacks Delphi això és un clàssic: si encara hi ha Borland BDE, estructures Paradox antigues o cadenes de controladors difícils de mantenir, ARM64 es converteix en un catalitzador. Una BDE-ablösung i la migració a una BDE-Ablösung mit nativer Anbindung amb una estratègia clara de drivers de BD redueixen significativament els riscos de plataforma.

Punts de comprovació concrets:

• Quines BD s’estan utilitzant (SQL Server, PostgreSQL, MariaDB, Firebird, engines locals)?
• Quins drivers s’utilitzen (ODBC, client natiu, BDE-Ablosung mit nativer Anbindung-drivers, OLE DB)?
• On es troben els connection-strings i DSNs (per usuari, per màquina, a l’instal·lador)?
• Existeixen dependències a drivers ODBC de 32 bits o providers antics?

Particularment amb SQL Server/ODBC un client ARM64 pot funcionar – però només si la cadena de drivers i la rutina d’instal·lació estan netes. No és un tema que vulgueu depurar «al camp».

4) Reporting, impressió, escaneig, PDF i fluxos d’output

L’output en aplicacions sectorials sovint és crític per al negoci: albarans, etiquetes, factures, protocols, comptadors, certificats, etiquetes d’enviament. Molts d’aquests fluxos depenen de components de reporting o de drivers/específics d’impressora/escàner.

Els entrebancs típics en Windows 11 ARM64 són:

• Drivers d’impressores d’etiquetes/especials només disponibles en x64
• Software/SDKs d’escàners sense suport ARM64
• Engines de reporting antics amb mòduls natius de preview/export
• Generació de PDF via „impressores virtuals“ en lloc d’una biblioteca

Un camí robust és estandarditzar els fluxos d’output: generar PDF/format Office mitjançant biblioteques, imprimir via interfícies estandarditzades, i encapsular els accessos a maquinari especial. On això no sigui possible cal una matriu de dispositius/drivers per ARM64 ben definida des d’un estat precoç.

5) Instal·ladors, actualitzadors, signatura de codi i operació

Mols projectes ARM64 no fallen pel programa, sinó per la distribució: el setup detecta malament l’arquitectura, no instal·la drivers, no registra COM, estableix rutes incorrectes o falla per polítiques de signatura de codi. També els actualitzadors automàtics (delta-updates, self-updaters) sovint depenen fortament de l’arquitectura.

Preguntes rellevants per a l’operació:

• Com s’instal·la (MSI, Inno Setup, updater propi)?
• Com s’instal·len les dependències (VC++ Runtimes, drivers, certificats)?
• Com es signa (EXE, DLL, instal·lador, paquets de drivers)?
• Com es prova: maquinari ARM64 real o només supòsits?

Per a les empreses això és una qüestió de governança: quan Windows 11 ARM64 apareix a la flota client cal que el deployment sigui reproducible – incloent rollback, capacitat de suport i versió clarament definida.

Estratègia: Windows 11 ARM64 com a «requisit no funcional» precoç

La manera econòmicament correcta d’abordar-ho és tractar ARM64 com un requisit no funcional (NFA) – similar a rendiment, seguretat o capacitat offline. Això vol dir: no esperar al sprint «quan arde», sinó establir-lo com una directriu definida per a l’arquitectura i la cadena de subministrament.

ARM64-Readiness-Check: inventari en lloc d’instint

Un check sòlid normalment comprèn:

• Inventari de dependències: tots els components de tercers, DLLs, drivers, SDKs, controls de navegador, mòduls criptogràfics, reporting.
• Anàlisi de build/pipeline: targets de build, empaquetatge, signatura, emmagatzematge d’artefactes, numeració de versions, reproducibilitat.
• Cadena d’instal·lació/actualització: lògica de setup, prerequisits, rutes del registre/sistema de fitxers, polítiques, permisos.
• Model d’operació: suport, logging, crash-dumps, telemetria (si existeix), pla de desplegament.

El resultat no hauria de ser només «ARM64: sí/no», sinó una llista prioritzada: quins bloquejos existeixen, quins mòduls estan afectats, quines alternatives hi ha i quina inversió és realista.

Matriz de decisió: natiu a ARM64 o desacoblar?

Per a cada dependència problemàtica cal una decisió clara:

• Substitut natiu ARM64 possible: actualització, canvi de fabricant, migració a una altra llibreria.
• La dependència pot externalitzar-se: p. ex. a un servei Windows, a un worker en segon pla o a un servidor central REST-Server.
• La dependència ha de romandre local: p. ex. perquè el maquinari està connectat directament al client. En aquest cas cal aprovacions de maquinari/drivers ARM64 vinculants.

Per a integracions, l’externalització sovint és la via més neta: el client queda com a UI + diàlegs sectorials, mentre que la lògica d’integració complexa s’executa en serveis controlats. Això dóna suport tant a ARM64 com a conceptes com actualitzacions centrals, models de drets i millor testabilitat.

Patrons d’arquitectura que estabilitzen projectes ARM64

Si Windows 11 ARM64 es planifica aviat, es poden prendre decisions arquitectòniques que evitin revisions costoses més endavant.

1) Capes clares: UI, lògica de negoci, integració, accés a dades

Els clients Delphi evolucionats sovint tenen «tot en un procés»: UI, regles de negoci, accés a dades, integració DMS, impressió i export. Això és mantenible mentre la plataforma sigui estable. Però quan apareixen variants de plataforma (ARM64, possiblement macOS, possiblement servidors de terminal) augmenta el valor d’una clara estratificació.

Objectiu pragmàtic:

• Capa UI: mínima, testable, sense dependències directes de drivers/SDKs.
• Lògica de negoci: tan neutra de plataforma com sigui possible, ben modelada.
• Capa d’integració: encapsula COM, formats de fitxer, connectors DMS/ERP, SDKs de dispositius.
• Accés a dades: consolidat (p. ex. FireDAC), límits de transacció clars, sense fragments SQL dispersos.

Això no és «acadèmic», sinó que rebaixa costos reals: si només la capa d’integració és problemàtica amb ARM64, no cal reconstruir tot el client.

2) Serveis i REST-servers com a ancoratge d’estabilitat

Molts sistemes B2B guanyen si es mantenen funcions centrals com a REST-Servers o com a Windows-/Linux-Services: comprovacions d’accés, fluxos documentals, validació de dades, export, import, interfícies amb ERP/DMS/CRM. Si aquestes funcions s’executen al servidor, la complexitat al client es redueix de manera considerable – i amb ella la superfície d’atac ARM64.

Divisions típiques que han funcionat:

• Client: diàlegs, visualització, lògica offline (si cal), integracions locals mínimes.
• REST-Server: operacions de negoci, validació, multi-tenant, registre centralitzat.
• Worker/Service: treballs programats, polling d’interfícies, generació de reports, exportacions en lot.

Això encaixa també amb models d’operació moderns: una funció que s’executa al servidor s’actualitza una sola vegada en lloc de fer-ho a cada client ARM64 individualment.

3) Un sistema de build, múltiples targets (x64 + ARM64) des del principi

Si ARM64 és un objectiu, la pipeline de build hauria de reflectir-ho. No com «farem un build especial més tard», sinó com estàndard: cada candidata de release es construeix de manera reproduïble per x64 (i, si està previst, ARM64), incloent signatura i empaquetament d’instal·lador.

El que importa no és tant l’eina com la disciplina:

• Nominar artefactes clarament (arquitectura al nom del paquet/estructura de carpetes).
• Separar valors de configuració per target (rutes, prerequisits, paquets de drivers).
• Definir smoke-tests per cada arquitectura (arrencada, login, connexió BD, impressió/PDF).

Això fa que ARM64 no sigui un «Big Bang», sinó un target addicional controlat.

Modernització Delphi: ARM64 com a oportunitat per reduir deute tècnic

Moltes empreses aprofiten nous requisits de plataforma per fer «tot de zero». Això és arriscat i sovint innecessari. És més econòmic utilitzar Windows 11 ARM64 com a directriu per a una modernització incremental: eliminar el deute tècnic allà on bloqueja ARM64 o posa en perill la capacitat de lliurament.

64-Bit i Unicode: no traslladar vells problemes

Si a la base de codi encara hi ha assumptes de 32 bits o herències d’antigues versions Delphi, reapareixen amb el canvi de plataforma. Tot i que ARM64 no vol dir automàticament «Unicode», molts projectes que aborden seriosament ARM64 aprofiten per assegurar que Unicode està ben implementat, que els camins a 64 bits estan establerts i que els temes de memòria/punters s’han netejat.

L’objectiu no és la perfecció, sinó un estàndard fiable: un codi que es pugui construir per a nous targets sense reproduir cada vegada la mateixa classe d’errors.

BDE-ablösung i accés a dades consolidat com a habilitador ARM64

Allà on encara existeixen capes d’accés històriques ( [[NBML_TERM_11_901e2bf2 ]], dades Paradox locals, accessos mixtos), una consolidació és una palanca amb efectes múltiples: codi més mantenible, desplegaments més estables, estratègia de drivers més clara. Amb FireDAC l’accés es pot unificar en molts escenaris, incloent-hi gestió central de paràmetres, estratègies de pooling i maneig net d’errors.

Important: una BDE-ablösung no és només «canviar components». Afecta la lògica de transaccions, tipus de dades, ordenacions, semàntica de filtres i parcialment també el model de dades. Per això ha de ser planificada i no una mesura d’urgència quan clients ARM64 apareguin sobtadament al camp.

Prova i assegurament de qualitat: ARM64 és planificable només si es mesura

Planificar ARM64 aviat també significa provar-lo – no fent proves completes de cada funció, sinó provant de manera dirigida les cadenes crítiques de risc. El pas més important és disposar d’un entorn de proves ARM64 real. L’emulació pot ajudar en casos puntuals, però no substitueix la pràctica amb maquinari real, drivers reals i polítiques de seguretat reals.

Smoketest mínim ARM64: què s’ha de cobrir realment aviat

Un conjunt de smoke-tests pragmàtic però efectiu per a cada candidata de release:

• Arrencada del programa, login, funcions UI bàsiques
• Connexió BD (incloent autenticació, certificats, DNS/Proxy si és rellevant)
• Un procés clau «end-to-end» (p. ex. crear comanda, desar, imprimir/exportar)
• Updater/instal·lador: instal·lació nova i actualització entre versions
• Logging/diàlegs d’error: les diagnòstics també són útils en ARM64?

Això fa visibles aviat els bloquejos típics ARM64: DLLs mancants, drivers incorrectes, problemes d’setup, requisits de permisos inesperats.

Capacitat de diagnosi: crash-dumps, logs, transparència de versions

Quan ARM64 està a la flota es produiran casos de suport – només per noves combinacions de drivers. Per això val la pena estandarditzar diagnòstics: IDs de build clars, logs informatius, rutes d’instal·lació i actualització reproduïbles. Això no és específic d’ARM64, però ARM64 fa que les deficiències en aquestes àrees es tornin ràpidament costoses.

Desplegament i operació: flotes mixtes sense caos

La majoria d’empreses operaran a mig termini flotes mixtes de clients: una part x64, una part ARM64. La clau és gestionar aquest estat de manera intencional.

Empaquetatge: instal·ladors separats, detecció clara, vies de descàrrega inequívoces

A la pràctica funciona millor quan els instal·ladors/paquets són inequívocs: el paquet x64 és x64, el paquet ARM64 és ARM64. «Un instal·lador per a tot» sembla còmode, però s’enreda ràpidament (lògica de comprovació, prerequisits, rutes de drivers, signatura, reparació d’instal·lació). Per a desplegaments empresarials controlats, la claredat sovint és el camí més robust.

Estratègia d’actualització: sense camins especials per a ARM64

ARM64 no hauria de ser un cas especial en el procés d’actualització. L’objectiu: mateixa freqüència de releases, mateixa numeració de versió funcional, però artefactes separats. Si ARM64 només s’actualitza «manualment», s’introdueixen desviacions a la flota que després disparen els costos de suport.

Documentar integracions amb cura

Moltíssims problemes ARM64 no estan al vostre codi, sinó a les integracions: connector ERP, client DMS, servei de signatura, software d’escàner, impressora d’etiquetes. Una llista d’integracions mantenida amb versions i indicacions d’arquitectura és ja de per si útil per a sistemes B2B – i fa les decisions sobre ARM64 transparents.

Què haurien de fer les empreses ara mateix (sense accionarisme)

Planificar ARM64 aviat no vol dir reestructurar-ho tot immediatament. Vol dir respondre les preguntes correctes a temps i eliminar bloquejos mentre l’esforç és planificable. Un procediment provat és:

• 1) Inventari (2–10 dies segons la mida del sistema): dependències, instal·ladors, drivers, accés a dades, COM, reporting.
• 2) Imatge objectiu i ruta: què ha de ser natiu al client? Què serà servei/REST? Quins components es reemplaçaran?
• 3) Proof of Feasibility: un build ARM64 funcional amb instal·lador i un cas d’ús end-to-end.
• 4) Enduriment pas a pas: funcions restants, proves, cadena d’actualització, capacitat de diagnosi.

Així no neix un «projecte ARM64» que funcioni aïllat durant mesos, sinó una ampliació controlada de la capacitat de lliurament.

Conclusió: Windows 11 ARM64 no és una moda, sinó un indicador precoç de maduresa tècnica

Windows 11 ARM64 es farà realitat per a moltes empreses – per adquisició de maquinari, requisits de mobilitat o estandardització. Per a aplicacions Delphi el repte real no és només el codi font, sinó el sistema complet de dependències, processos d’instal·lació i actualització, integracions i drivers. Qui planifica ARM64 aviat pot aclarir aquests punts de manera estructurada en lloc d’intentar «parchejar» sota pressió de temps.

Al final, ARM64 és un banc de prova útil: com de ben desacoblada, testable i lliurable és la vostra aplicació? Si responeu aquesta pregunta ara, no només guanyeu opcions de plataforma, sinó també una base més estable per a modernització, serveis, arquitectures REST i mantenibilitat a llarg termini.

Kontaktieren Sie Net-Base Software GmbH, wenn Sie Windows 11 ARM64 in Ihrer Delphi-Roadmap belastbar bewerten und mit einem klaren technischen Pfad umsetzen möchten.