Windows 11 ARM64 amb Delphi a les empreses: opcions, riscos i un pla de migració sòlid

Windows-dispositius amb CPU ARM64 (ARM64 és una arquitectura de processador de 64 bits, coneguda dels SoC mòbils i cada cop més present també en portàtils professionals) ja no són només „Exoten“ en moltes empreses. Arriben a través de flotes de portàtils estandarditzades, una major autonomia de la bateria, noves funcions de seguretat a nivell de maquinari i una diversificació estratègica de la cadena de subministrament. Com a mínim quan els departaments operatius adquireixen nous dispositius o els OEMs ofereixen determinats models només com a Windows on ARM, es planteja als responsables de TI la qüestió pràctica: Com es comporta el nostre Delphi-basat programari empresarial sota Windows 11 ARM64 – i com assegurem l’operació, el suport i la continuïtat del desenvolupament?

El nucli de la qüestió és: Windows 11 ARM64 amb Delphi a les empreses és menys una pregunta exclusiva de desenvolupament i més una qüestió d’interdependències, estratègies de desplegament, controladors, interfícies i del comportament real al camp. A la pràctica hi ha tres vies: mantenir l’execució per emulació, compilacions natives ARM64 o un model de transició que redueixi els riscos de manera controlada. Aquest article ordena els obstacles típics i mostra un camí robust que funciona en planificació de TI, desplegament i operació – sense un reflex de „fer-ho tot de nou“.

Per què Windows 11 ARM64 esdevé rellevant ara

Windows on ARM no és nou, però les condicions marc han canviat: els dispositius són disponibles en l’entorn empresarial, Windows 11 aporta una emulació x64 visiblement més madura, i els fabricants de programari lliuren cada cop més variants ARM64. Per a les empreses això vol dir: ARM64 no apareix com un projecte pilot aïllat, sinó com una plataforma que s’integra en la planificació de compres i del cicle de vida.

Per a solucions de programari pròximes als processos, el problema no és tant la CPU com la realitat de perifèrics i integració: impressió, targetes de signatura, escàners, add-ins d’Office, components COM (COM és el model de components de Microsoft per a la integració d’aplicacions i biblioteques), extensions de shell, clients VPN o agents de seguretat. Si alguna d’aquestes peces no és compatible amb ARM64, sorgeix feina de suport – i sovint se sol responsabilitzar „l’aplicació“.

Classificació: Què significa ARM64 tècnicament per a aplicacions Delphi?

Les aplicacions Delphi en l’entorn empresarial solen ser clients d’escriptori clàssics per a Windows (frequentment VCL, és a dir la Visual Component Library per a interfícies Windows) amb accés a bases de dades (p. ex. mitjançant la BDE-substitució amb connexió nativa, la capa d’accés a dades de Delphi) i una combinació d’integracions locals i remotes. Sota Windows 11 ARM64 s’hi configuren tres modes d’execució:

1) Execució nativa ARM64

L’aplicació i totes les biblioteques natives (DLLs) existeixen en versió ARM64. A llarg termini és l’opció més neta, perquè fa previsible el rendiment i l’estabilitat i evita les condicions límit de l’emulació. Només és realista, però, si totes les dependències natives s’actualitzen: controladors de base de dades, impressió/previsualització, motor PDF, biblioteques criptogràfiques, SDKs d’OCR/escaneig, controladors de dongles de maquinari, etc.

2) Emulació x64 sota Windows 11 ARM64

Windows 11 pot emular aplicacions x64. Per a molts clients d’escriptori purs això funciona sorprenentment bé. A la pràctica, però, l’emulació no és una „targeta lliure“: en el moment en què intervenen controladors, integracions de l’explorador o components en procés (DLL que es carreguen al procés), l’arquitectura esdevé rellevant. Un procés x64 no pot carregar una DLL ARM64 i a l’inrevés. Precisament aquest límit sovint determina si „funciona“ o „no funciona“.

3) Híbrid: client ARM64, desacoblar components x64

Un camí de transició és extreure components x64 crítics del procés: p. ex. com a servei extern, com a REST-backend (REST és un model d’interfície basat en HTTP) o com a utilitat separada. Això és menys elegant que „tot nadiu“, però sovint la ruta més econòmica per garantir l’operació i modernitzar les dependències de manera progressiva.

Windows 11 ARM64 amb Delphi a les empreses: les dependències típiques que determinen l’èxit

En els projectes es veu ràpidament: no la GUI és el coll d’ampolla, sinó l’ecosistema. Una anàlisi estructurada de dependències estalvia setmanes de prova i error.

DLLs natius i SDKs: el risc invisible

Moltes aplicacions Delphi integren DLLs de tercers: generació de PDF, codi de barres/QR, processament d’imatges, xifrat, llibreries de comunicació propietàries. En ARM64 és taxatiu: Una DLL ha de coincidir amb l’arquitectura del procés. L’emulació només ajuda si tot el procés es manté x64. Un cop es vol executar de manera nativa, aquestes llibreries han d’existir en ARM64 o ser substituïdes.

Consell pràctic per a IT: demaneu al responsable del programari una llista de quines DLLs es troben al directori d’instal·lació i quines es carreguen a través de rutes del sistema. Aquesta és la base per avaluar la disponibilitat dels fabricants i les alternatives.

COM, automatització d’Office i extensions del shell

COM s’utilitza sovint en el dia a dia de l’empresa, sense que es nomeni així: integració amb Outlook, exportació d’Excel via Automation, clients DMS, gestors de previsualització a l’Explorer, extensions del menú contextual. El problema en ARM64 no és tant COM en si, sinó l‘acoblament per bitness: els servidors COM en procés (components COM basats en DLL) han de ser de la mateixa arquitectura. El COM fora de procés (servidors basats en EXE) és més flexible, perquè pot executar-se en un procés separat.

Si la vostra aplicació Delphi fa servir, p. ex., una antiga DLL COM de 32 bits o de 64 bits, això és un bloqueig en una execució nativa ARM64. Emulada com x64 pot funcionar, sempre que totes les dependències COM també siguin x64 i no hi intervinguin components exclusius per ARM64.

Impressió, PDF i l’ecosistema de controladors

Els problemes d’impressió són un clàssic en els canvis de plataforma. En Windows 11 ARM64 és decisiu si el fabricant de la impressora proporciona controladors ARM64 o si es poden utilitzar controladors de classe Universal Print/IPP (IPP és un protocol d’impressió estandarditzat). També les impressores PDF, la impressió en lots, la impressió d’etiquetes i dispositius especials (p. ex. impressores tèrmiques) poden dependre de controladors que només existeixen per a x64.

Per a la direcció d’IT i l’administració, la conseqüència important és: els desplegaments ARM64 han d’estar alineats amb l’estratègia d’impressió. „L’aplicació no imprimeix“ sovint significa „el controlador no existeix“ o „la canalització d’impressió és diferent“.

Accés a dades: FireDAC, ODBC/OLE DB i clients de base de dades

A nivell de dades val la pena una separació clara entre protocol i biblioteca client. BDE-Ablosung mit nativer Anbindung pot, segons la base de dades, treballar amb clientlibs natius o amb controladors. Si, p. ex., es necessita un client Oracle, un client PostgreSQL més antic o un controlador ODBC específic, aquest ha d’existir per a ARM64 — o cal optar per una arquitectura que encapsuli l’accés a dades al costat del servidor (p. ex. a través de REST-serveis o un Windows-/Windows- i Linux-serveis).

Per a un funcionament estable això és una palanca central: com menys el client d’escriptori estigui lligat directament a controladors de base de dades i a «stacks» locals de base de dades, més fàcil serà ARM64. Això també s’aplica des del punt de vista de la seguretat: credencials d’accés a la base de dades, certificats i regles de xarxa es poden gestionar de manera més consistent al costat del servidor.

Criptografia, smartcards, signatures, VPN, EDR

Molts processos de negoci depenen avui de components criptogràfics: S/MIME, certificats de client, middleware per a smartcards, targetes de signatura, inspecció TLS en proxies. A més hi ha solucions d’endpoint security (EDR és Endpoint Detection and Response) i clients VPN. Aquests components han de ser compatibles amb ARM64; si no, es pot generar un problema del tipus «el dispositiu està present però no pot accedir a la xarxa».

Per a l’aplicació Delphi això vol dir: si, p. ex., utilitzeu certificats del magatzem de certificats Windows o gestioneu TLS mitjançant components del sistema, això sol ser menys crític que si una DLL criptogràfica d’un tercer està integrada dins del procés.

Matrriu de decisió: emulació o portació nativa a ARM64?

Les empreses necessiten una decisió que reflecteixi la realitat del suport i del cicle de vida. Una pregunta simple de tipus sí/no («La portem a terme?») rarament és útil. Millor una matriu que ponderi dependències i riscos:

• Client pur amb APIs estàndard Windows (fitxer, xarxa, impressió via controladors estàndard): l’emulació pot ser suficient a curt termini; una versió nativa per ARM64 és la solució neta a mig termini.
• Client amb moltes DLL natives de tercers (PDF, OCR, maquinari): primer comprovar la disponibilitat i després decidir. Sovint té sentit un camí híbrid.
• Client amb COM-DLLs / extensions de shell: s’han d’esperar conflictes d’arquitectura; comprovar el desacoblament fora de procés.
• Client amb un zoo de controladors de base de dades: o bé consolidar controladors o desplaçar l’accés a dades a serveis.
• Alta regulació / signatura / smartcard: verificar aviat la compatibilitat ARM64 de la cadena de seguretat i del middleware.

Important: l’emulació no és de «segona classe», però constitueix un risc operatiu si preveu dispositius ARM64 a la flota a llarg termini. Ben aviat —amb actualitzacions majors, canvis de controladors o canvis d’agents de seguretat— no voldreu quedar-vos amb una cadena de casos especials.

Un camí de migració sòlid: d’avui a ARM64 sense Big Bang

Per a responsables d’IT i de projecte, un camí és adequat si es pot desplegar en ones, té criteris d’acceptació clars i no sobrecarrega el suport. En entorns Delphi s’ha demostrat eficaç un procediment en cinc passos.

Pas 1: Inventari amb «òptica operativa»

Registreu no només mòduls, sinó sobretot punts operatius:

• Quines classes de dispositius: ordinadors portàtils, dispositius robustos (rugged devices), terminals?
• Quina perifèria: impressores, escàners, lectors de targetes, etiquetadores?
• Quines integracions: Office, DMS, ERP, serveis locals, components del navegador?
• Quina forma d’instal·lació: MSI, Setup-EXE, ClickOnce, instal·lació manual?
• Quins drets: cal ser administrador, serveis locals, regles de tallafocs?

Aquesta visió fa evident de seguida si „només un client“ en realitat suposa cinc dependències de sistema.

Pas 2: Comprovació de compatibilitat amb un pilot ARM64 representatiu

El pilot no hauria de ser „el dispositiu més bonic“, sinó un candidat típic de la flota objectiu. Proveu de manera conscient els camins crítics: impressió en totes les variants, exportació/importació, signatura, fora de línia/en línia, actualitzacions, canvi de tenant, escenaris amb proxy/VPN. Documenteu les desviacions com incidents d’operació, no com errors d’implementació. Així la priorització es manté clara.

Pas 3: Reduir dependències – primer les que generen més esforç de suport

Mesures típiques que aporten molt en el dia a dia:

• Estandarditzar la ruta PDF/impressió: allunyar-se de DLLs de impressora propietàries i optar per canalitzacions estables i provades.
• Desacoblar la integració d’Office: en lloc d’add-ins in-process, preferir formats d’exportació i la generació de documents al costat del servidor.
• Consolidar l’accés a la base de dades: una ruta de controladors definida en lloc d’«ODBC segons l’estació de treball».
• Encapsular la connexió de maquinari: si és possible, mitjançant processos/serveis externs que es puguin actualitzar de manera independent.

Pas 4: Modernitzar el desplegament i la capacitat d’actualització

ARM64 és una bona ocasió per netejar la instal·lació i les actualitzacions. Per a les empreses, aquí no compten les funcionalitats, sinó la capacitat de rollback, la reproductibilitat i la conformitat amb les polítiques. Comproveu:

• Paquetització: MSI vs. MSIX (MSIX és el format d’aplicació modern de Microsoft amb instal·lació/desinstal·lació neta i signatura).
• Signatura: Code Signing (signatura digital d’EXE/DLL) redueix la fricció amb SmartScreen i EDR i és rellevant per a desplegaments controlats.
• Gestió de configuració: separació dels fitxers del programa i la configuració, rutes clares, cap dependència de registre «amagada».
• Canals d’actualització: Pilot, Ring 1, Ring 2 – amb telemetria/logging a nivell d’aplicació i d’operació.

Pas 5: ARM64 nadiu on realment val la pena

Les compilacions natives ARM64 tenen sentit quan (a) teniu les dependències sota control i (b) l’aplicació es desenvoluparà a llarg termini. Típicament val la pena per a clients centrals que molts usuaris utilitzen diàriament i que ja esteu modernitzant. Per a eines poc utilitzades, l’emulació x64 pot ser una transició acceptable, sempre que el suport i la seguretat hi donin cobertura.

Impulsos d’arquitectura: ARM64 com a ocasió per reforçar interfícies i serveis

Moltes Delphi-arquitectures han crescut històricament com a „client gruixut“. Això funciona, però vincula l’operació i les actualitzacions més estretament a configuracions particulars d’estació de treball. ARM64 fa visible on aquest acoblament esdevé car. Per tant, un pas pragmàtic de modernització sovint no és „UI nova“, sinó replantejar les interfícies.

Més estabilitat mitjançant responsabilitats en el costat del servidor

Si la lògica crítica, l’accés a dades o els processos de documents es traslladen a un servei central (Windows- i Linux-services o Windows- und Linux-Services, és a dir, un servei en segon pla sense UI interactiva), guanyeu:

• versions uniformes de controladors i biblioteques,
• seguretat més controlable (certificats, secrets, xarxa),
• menor complexitat al client (ARM64, x64, en el futur també altres plataformes),
• punts de monitorització i registres més clars.

Per als responsables de TI això és un avantatge operatiu real: els problemes es poden reproduir més ràpidament al costat del servidor, en lloc de quedar vinculats a „un portàtil específic“.

REST-API com a capa de desacoblament

Una REST-API no és automàticament «modern», però constitueix un desacoblament robust entre clients i backend. Defineix amb claredat quines dades i accions estan permeses i es pot assegurar de manera neta (per exemple mitjançant tokens, certificats o SAML 2.0 com a estàndard d’identitat en entorns empresarials). Per a ARM64 això vol dir: el client ha de gestionar menys coneixements operacionals sobre bases de dades, controladors i detalls de xarxa.

Encara que no ho reimplementin tot de seguida: ja un petit component API ben limitat (p. ex. generació de documents, comprovació de llicències, comprovació de dades mestres) pot eliminar dependències del client i, per tant, reduir riscos relacionats amb ARM64.

Proves i qualitat: què haureu de verificar de manera diferent amb ARM64

Molts equips proven el programari d’escriptori principalment en termes de funcionalitat. Amb ARM64 hauríeu de centrar-vos més en proves operatives, perquè els patrons d’error són diferents: no «càlcul incorrecte», sinó «component que no es carrega», «falta de controlador», «actualització que falla», «integració amb Office que es trenca».

Llista de comprovació per a l’aprovació en entorns ARM64

• Instal·lació/Desinstal·lació: neta, sense restes, sense solucions alternatives d’administrador.
• Ruta d’actualització: actualitzacions a través de diverses versions, escenari de reversió, verificació de signatura.
• Registre: registres centrals, codis d’error clars per problemes de càrrega de DLL, rutes d’impressió traçables.
• Rendiment: temps d’inici, operacions de dades, llistes/informes grans — mesurar per separat sota emulació i de manera nativa.
• Perifèrics: perfils d’impressores, impressió especial, fluxos de treball d’escàners, funcions de targeta intel·ligent.
• Seguretat: interacció EDR/AV, proxy/TLS, emmagatzematge de certificats, operació amb mínims privilegis.

La documentació és important: si un problema es produeix per drivers ARM64 inexistents, això no és una «correcció d’errors a Delphi», sinó una decisió de compra o d’estandardització.

Operacions i suport: com integrar ARM64 en el dia a dia

En el dia a dia importa la rapidesa en la resolució dels casos de suport. Amb ARM64 val la pena augmentar proactivament la capacitat de suport:

Perfils d’equip estandarditzats i aprovacions clares

Definiu els models ARM64 compatibles o almenys perfils mínims (estratègia de controladors, estratègia d’impressió, versions dels agents de seguretat). Un «funciona en ARM64» sense aquest marc condueix a entorns inconsistents i, per tant, a incidències difícils de reproduir.

Capacitat de diagnosi a l’aplicació

Fins i tot sense un enfocament per a desenvolupadors, té sentit exigir això al software: una pàgina d’informació del sistema que indiqui l’arquitectura (x64 emulat vs. ARM64 natiu), rutes importants, versions de components clau i la configuració d’impressió redueix notablement els temps de suport. Això no és un «nice to have», sinó higiene operativa.

Llicenciament i dongles

Si hi ha dongles de maquinari o controladors de llicència antics implicats, ARM64 pot esdevenir ràpidament crític. En molts entorns convé migrar la llicenciació a mecanismes basats en xarxa o a la part de servidor. Això redueix la dependència de controladors als equips finals i fa que la flota sigui més substituïble.

Què significa això per a la vostra estratègia Delphi?

Delphi és en el context empresarial sovint un element estable per a clients d’escriptori i serveis. Windows 11 ARM64 no és un argument „contra Delphi“, però sí un argument a favor d’una encapsulació més neta de les dependències i d’una modernització orientada a l’operativa: menys controladors especials locals, menys components en procés, interfícies més clares, desplegament millor.

Si avui ja esteu en un camí de modernització (per exemple BDE-Ablösung, migració a 64 bits, integració més estreta de REST, accés de dades consolidat amb FireDAC), llavors ARM64 sovint és „només“ un punt objectiu addicional que fa més clares les prioritats. Si, en canvi, la vostra aplicació depèn molt de controladors antics, DLLs propietàries i configuracions especials d’estació de treball, ARM64 és una ocasió raonable per fer transparents aquests riscos i reduir-los de manera planificable.

Conclusió: ARM64 és menys un projecte de portabilitat que un projecte d’arquitectura i d’operacions

Per a les empreses, Windows 11 ARM64 és sobretot una qüestió de plataforma en adquisicions, seguretat i suport. Per al programari empresarial basat en Delphi, l’èxit no es decideix per una opció del compilador, sinó per la cadena de controladors, DLLs, integracions COM, accés a dades i processos d’actualització. Un camí sòlid és: primer fer visibles les dependències i els camins d’operació, després provar amb equips pilot, a continuació desacoblar de manera selectiva i professionalitzar el desplegament — i lliurar compilacions natives ARM64 allà on aportin benefici i estabilitat a llarg termini.

Si voleu introduir Windows 11 ARM64 a la vostra flota i, al mateix temps, assegurar de manera planificable aplicacions, perifèrics i interfícies basats en Delphi, parli amb nosaltres sobre una presa d’inventari estructurada i un camí de migració realista:

En l’àmbit tècnic, també tenen un paper important Delphi ARM64 Windows i l’emulació X64 Windows 11 quan integracions, fluxos de dades i evolució han de funcionar conjuntament de manera coherent.

Parli del projecte o d’una iniciativa de modernització amb Net-Base.