Windows 11 ARM64 s Delphi u poduzećima: opcije, rizici i pouzdan migracijski put

Windows-uređaji s ARM64-CPU (ARM64 je 64‑bit procesorska arhitektura, poznata iz mobilnih SoC-ova i sve češće i iz poslovnih prijenosnika) u mnogim tvrtkama više nisu samo „exoten“. Dolaze kroz standardizirane flote prijenosnika, dulje trajanje baterije, nove sigurnosne funkcije u hardveru i strateško diverzificiranje lanca nabave. Najkasnije kad poslovne jedinice nabavljaju nove uređaje ili OEM-i određene modele nude samo kao Windows on ARM, za odgovorne u IT-u postavlja se praktično pitanje: Kako se ponaša naša Delphi-bazirana poslovna softverska rješenja pod Windows 11 ARM64 – i kako osigurati rad, podršku i daljnji razvoj?

Ključna stvar je: Windows 11 ARM64 s Delphi u poduzećima manje je pitanje isključivo razvoja, a više pitanje ovisnosti, strategija deploya, drajvera, sučelja i stvarnog ponašanja na terenu. U praksi postoje tri pristupa: nastavak rada preko emulacije, izvorne ARM64 build‑ove ili prijelazni model koji kontrolirano smanjuje rizike. Ovaj tekst kategorizira tipične zamke i pokazuje pouzdan put koji funkcionira u IT‑planiranju, rolloutu i radu – bez refleksa „sve iznova“.

Zašto Windows 11 ARM64 sada postaje relevantan

Windows on ARM nije novost, ali su se okolnosti promijenile: uređaji su dostupni u poslovnom okruženju, Windows 11 donosi znatno zreliju x64‑emulaciju, a proizvođači softvera sve češće nude ARM64 varijante. Za poduzeća to znači: ARM64 se ne pojavljuje kao jednokratan pilotski projekt, već kao platforma koja ulazi u planove nabave i životnog ciklusa.

Za procesno orijentirana softverska rješenja problem je manje sama CPU arhitektura, a više stvarna situacija perifernih uređaja i integracija: pisači, kartice za potpis, skeneri, Office‑dodaci, COM‑komponente (COM je Microsoftov model komponenti za integraciju aplikacija i biblioteka), shell‑proširenja, VPN‑klijenti ili sigurnosni agenti. Ako nešto od toga nije kompatibilno s ARM64, nastaje dodatni napor u podršci – i često se onda „aplikacija“ smatra odgovornom.

Procjena: Što ARM64 tehnički znači za Delphi‑aplikacije?

Delphi‑aplikacije u poslovnom okruženju često su klasični Windows desktop‑klijenti (često VCL, tj. Visual Component Library za Windows‑GUI‑e) s pristupom bazi podataka (npr. preko BDE‑Ablösung s izvornom vezom, Delphi‑sloj za pristup podacima) i mješavinom lokalnih i udaljenih integracija. Pod Windows 11 ARM64 pojavljuju se pritom tri načina izvođenja:

1) Nativno izvođenje na ARM64

Aplikacija i sve nativne biblioteke (DLL‑ovi) postoje kao ARM64. Dugoročno je to najčišća opcija jer omogućuje predvidivu izvedbu i stabilnost te izbjegava rubne uvjete emulacije. Međutim, realno je izvedivo samo ako sve nativne ovisnosti prate: upravljački programi za baze podataka, ispiso/preview, PDF‑engine, kripto‑biblioteke, OCR/scan‑SDK‑ovi, drajveri za hardverske dongle‑ove itd.

2) x64‑Emulation unter Windows 11 ARM64

Windows 11 može emulirati x64-aplikacije. Za mnoge čiste desktop-klijente to iznenađujuće dobro funkcionira. U praksi emulacija međutim nije „besplatna karta“: čim su uključeni upravljački programi, integracije ljuske ili In-Process-komponente (DLL‑ovi koji se učitavaju u proces), odlučuje arhitektura. x64-proces ne može učitati ARM64-DLL i obratno. Upravo ta granica često odlučuje o „radi“ ili „ne radi“.

3) Hibridno: ARM64-klijent, odvajanje x64-komponenti

Put prijelaza je izvući kritične x64-komponente iz procesa: npr. kao vanjski servis, kao REST-backend (REST je HTTP-baziran model sučelja) ili kao zaseban pomoćni program. To je manje elegantno od „sve nativno“, ali često najisplativija ruta za osiguranje rada i postupnu modernizaciju ovisnosti.

Windows 11 ARM64 s Delphi u poduzećima: tipične ovisnosti koje odlučuju o uspjehu

U projektima brzo postane jasno: usko grlo nije GUI, nego ekosustav. Strukturirana analiza ovisnosti ovdje štedi tjedne trial-and-error rada.

Izvorne DLL-ove i SDK-ove: nevidljiv rizik

Mnoge Delphi-aplikacije uključuju DLL-ove trećih strana: generiranje PDF‑ova, barkod/QR, obrada slika, enkripcija, vlasničke komunikacijske biblioteke. Na ARM64 vrijedi strogo pravilo: DLL mora odgovarati arhitekturi procesa. Emulacija pomaže samo ako cijeli proces ostane x64. Čim se želi ići nativno, te biblioteke moraju biti dostupne u ARM64 verziji ili ih je potrebno zamijeniti.

Praktičan savjet za IT: zatražite od odgovorne osobe za softver popis koji DLL-ovi se nalaze u instalacijskom direktoriju i koji se učitavaju putem sistemskih putanja. To je osnova za procjenu sposobnosti proizvođača i alternativa.

COM, Office-automatizacija i proširenja ljuske

COM se u svakodnevnom poslovanju često koristi, a da se tako i ne naziva: integracija s Outlookom, izvoz u Excel preko automatizacije, DMS-klijenti, preview‑handler u Exploreru, proširenja kontekstnog izbornika. Problem na ARM64 nije toliko sam COM, koliko vezanost po bitnosti: In-Process-COM-serveri (COM-komponente u obliku DLL‑ova) moraju biti iste arhitekture. Out-of-Process-COM (EXE‑serveri) je fleksibilniji jer može raditi u odvojenom procesu.

Ako vaša Delphi-aplikacija, npr., koristi staru 32‑bitnu ili 64‑bitnu COM-DLL, to pri nativnom ARM64 izvođenju postaje blocker. Emulirano kao x64 može funkcionirati – sve dok su sve COM-ovisnosti također x64 i dok se u sustav ne umeću ARM64‑samo dijelovi.

Ispis, PDF i okruženje upravljačkih programa

Problemi s ispisom su klasika pri promjeni platforme. Kod Windows 11 ARM64 je ključno hoće li proizvođač pisača osigurati ARM64‑upravljačke programe ili se mogu koristiti Universal Print/IPP klase upravljačkih programa (IPP je standardizirani protokol ispisa). Također PDF‑pisači, batch‑ispis, etiketiranje i specijalni uređaji (npr. termalni pisači) mogu ovisiti o upravljačkim programima koji postoje samo za x64.

Za IT‑rukovodstvo i administraciju važna posljedica je: ARM64‑rolloutovi moraju se uskladiti s ispisnom strategijom. „Aplikacija ne ispisuje“ često znači „nema upravljačkog programa“ ili „ispisna pipeline je drugačija“.

Pristup podacima: FireDAC, ODBC/OLE DB i klijenti baza podataka

Na razini podataka isplati se jasna razdvajanje između protokola i klijentske knjižnice. BDE-Ablosung mit nativer Anbindung može, ovisno o bazi podataka, raditi s izvornim klijentskim bibliotekama ili s drajverima. Ako je npr. potreban Oracle-klijent, stariji PostgreSQL-klijent ili specifični ODBC-drajver, mora postojati verzija za ARM64 – ili se oslonite na arhitekturu koja pristup podacima kapsulira na strani servera (npr. preko REST-servisa ili jednog Windows-/Windows- i Linux-Services).

Za stabilan rad to je središnji poluga: što je manje desktop-klijent izravno vezan uz DB-drajvere i lokalne „Stacks“, to je jednostavnije uvesti ARM64. To vrijedi i iz perspektive sigurnosti: pristupni podaci za bazu, certifikati i mrežna pravila mogu se dosljednije upravljati na strani servera.

Kripto, pametne kartice, potpisi, VPN, EDR

Mnogi poslovni procesi danas ovise o kriptografskim komponentama: S/MIME, klijentski certifikati, middleware za pametne kartice, kartice za potpis, TLS-inspekcija u proxyjima. Tu su i rješenja za zaštitu krajnjih točaka (EDR je Endpoint Detection and Response) i VPN-klijenti. Te komponente moraju podržavati ARM64, inače se pojavljuje problem „uređaj postoji, ali mu se ne dozvoljava pristup mreži“.

Za Delphi-aplikaciju to znači: ako, primjerice, koristite certifikate iz Windows-spremnika certifikata ili TLS preko sistemskih komponenti, to je najčešće manje kritično nego kad u procesu visi specifična DLL treće strane za kriptografiju.

Matrica odluke: emulacija ili nativno ARM64-portiranje?

Tvrtke trebaju odluku koja odražava realnost podrške i životnog ciklusa. Jednostavno pitanje da/ne („Portiramo li?“) rijetko je korisno. Bolje je matrica koja teži i vrednuje ovisnosti i rizike:

• Čisti klijent sa standardnim Windows-API-jem (datoteka, mreža, ispis preko standardnih drajvera): emulacija može kratkoročno biti dovoljna; nativni ARM64 je srednjoročno čistije rješenje.
• Klijent s mnogim izvornim DLL-ovima trećih strana (PDF, OCR, hardver): prvo provjerite dostupnost, pa donesite odluku. Često je smislen hibridni put.
• Klijent s COM-DLL-ovima / proširenjima ljuske: očekujte arhitektonske konflikte; razmotrite dekompoziciju izvan procesa (Out-of-Process).
• Klijent s izravnim zoo-om DB-drajvera: ili konsolidirajte drajvere ili premjestite pristup podacima u servise.
• Visoka regulativa / potpis / pametna kartica: rano verificirajte ARM64-sposobnost lanca sigurnosnih i middleware komponenti.

Važno: emulacija nije „druga klasa“, ali predstavlja operativni rizik ako dugoročno planirate ARM64-uređaje u floti. Najkasnije pri većim updateima, promjenama drajvera ili izmjenama security-agenta ne želite sjediti na lancu iznimaka.

Pouzdan migracijski put: Od danas do ARM64 bez Big Bang

Za IT i projektne odgovorne put je dobar ako se može uvesti u valovima, ima jasne kriterije prihvata i ne preoptereti podršku. U Delphi-okruženjima pokazao se postupak u pet koraka.

Korak 1: Inventura s „operativnim naočalama“

Zabilježite ne samo module, nego prije svega operativne točke:

• Koje klase uređaja: prijenosna računala, rugged uređaji, terminali?
• Koja periferija: pisači, skeneri, čitači kartica, labeleri?
• Koje integracije: Office, DMS, ERP, lokalni servisi, komponente preglednika?
• Koji način instalacije: MSI, Setup-EXE, ClickOnce, ručno postavljanje?
• Koja prava: potreban admin, lokalne usluge, pravila vatrozida?

Ovaj pregled brzo pokazuje znači li „samo jedan klijent“ zapravo pet ovisnosti sustava.

Korak 2: Provjera kompatibilnosti s reprezentativnim ARM64-pilotom

Pilot ne bi trebao biti „najljepši uređaj“, nego tipični kandidat iz ciljne flote. Svjesno testirajte kritične tokove: ispis u svim varijantama, izvoz/uvoz, potpis, offline/online, nadogradnje, prebacivanje mandanta, proxy/VPN scenariji. Dokumentirajte odstupanja kao operativne incidente, a ne kao bugove za razvoj. Tako ostaje prioritetizacija čista.

Korak 3: Smanjivanje ovisnosti – najprije one s najvećim utjecajem na podršku

Tipične mjere koje u praksi mnogo pomažu:

• Standardizirati PDF-/tok ispisa: udaljiti se od vlasničkih DLL-ova pisača prema stabilnim, testiranim procesima.
• Raskinuti integraciju s Officeom: umjesto In-Process add-ina radije provjeriti izvozne formate i generiranje dokumenata na strani poslužitelja.
• Konsolidirati pristup bazi podataka: jedan definirani put upravljačkog programa umjesto „ODBC ovisno o radnom mjestu“.
• Kapsulirati povezivanje hardvera: ako je moguće preko vanjskih procesa/usluga koje se mogu ažurirati zasebno.

Korak 4: Modernizirati deployment i sposobnost ažuriranja

ARM64 je dobar povod za sređivanje instalacije i ažuriranja. Za poduzeća ovdje ne računaju značajke, nego mogućnost rollbacka, reproducibilnost i usklađenost s politikama. Provjerite:

• Paketiranje: MSI vs. MSIX (MSIX je Microsoftov moderni format paketa aplikacija s čistom instalacijom/deinstalacijom i potpisom).
• Potpisivanje: Code Signing (digitalni potpis EXE/DLL) smanjuje trenje sa SmartScreen-om i EDR-om i relevantno je za kontrolirane rollout-e.
• Upravljanje konfiguracijom: odvajanje programskih datoteka i konfiguracije, jasne putanje, bez „skrivenih“ ovisnosti o registru.
• Kanali ažuriranja: Pilot, Ring 1, Ring 2 – s telemetrijom/logiranjem na razini aplikacije i operativnoj razini.

Korak 5: Native ARM64 tamo gdje se zaista isplati

Native ARM64 buildovi smisleni su kad (a) imate pod kontrolom ovisnosti i (b) aplikaciju dugoročno dalje razvijate. Obično se isplati za centralne klijente koje mnogi korisnici svakodnevno koriste i koje ionako modernizirate. Za rijetko korištene alate x64-emulacija može biti prihvatljiva prijelazna opcija, sve dok podrška i sigurnost to dopuštaju.

Arhitekturni impulsi: ARM64 kao povod za jačanje sučelja i servisa

Mnoge Delphi-okoline povijesno su narasle kao „debeli klijent“. To funkcionira, ali vezuje rad i ažuriranja jače uz pojedinačne konfiguracije radnih mjesta. ARM64 otkriva gdje ta sprega postaje skupa. Pragmatičan korak modernizacije stoga često nije „novi UI“, nego redefiniranje sučelja.

Viša stabilnost kroz odgovornosti na strani poslužitelja

Ako kritička logika, pristup podacima ili procesi dokumenata prijeđu u centralnu uslugu (Windows- und Linux-Services oder Windows- und Linux-Services, dakle pozadinska usluga bez interaktivnog UI-ja), dobivate:

• ujednačene verzije upravljačkih programa i biblioteka,
• bolje kontroliranu sigurnost (certifikati, tajne, mreža),
• manju kompleksnost na klijentu (ARM64, x64, ubuduće i druge platforme),
• jasnije točke za monitoring i logiranje.

Za IT-odlučitelje to je stvarna operativna prednost: problemi se server-side brže reproduciraju, umjesto da ostanu vezani uz „poseban notebook“.

REST-API kao sloj za odvajanje

REST-API nije automatski „moderan“, ali je robusno odvajanje između klijenata i backend-a. Jasno definira koje su podatke i akcije dozvoljene i može se dobro osigurati (npr. putem tokena, certifikata ili SAML 2.0 kao standarda identiteta u poslovnim okruženjima). Za ARM64 to znači: klijent mora nositi manje „svjetskog znanja“ o bazama podataka, upravljačkim programima i mrežnim detaljima.

Čak i ako ne želite odmah sve premjestiti: već mali, dobro ograničen API-komponent (npr. generiranje dokumenata, provjera licence, usklađivanje matičnih podataka) može ukloniti ovisnosti iz klijenta i time smanjiti rizike vezane uz ARM64.

Testiranje i kvaliteta: što biste pod ARM64 trebali drugačije provjeravati

Mnogi timovi testiraju desktop-softver prvenstveno funkcionalno. Kod ARM64 trebali biste više provoditi operativno testiranje, jer su obrasci pogrešaka drugačiji: ne „pogrešan izračun“, već „komponenta se ne učitava“, „nedostaje drajver“, „ažuriranje ne uspijeva“, „integracija s Officeom se prekida“.

Kontrolna lista za prihvat u ARM64 okruženju

• Instalacija/Deinstalacija: čisto, bez ostataka, bez administrativnih zaobilazaka.
• Put ažuriranja: nadogradnja preko više verzija, rollback scenarij, provjera potpisa.
• Logiranje: centralizirani logovi, jasni kodovi pogrešaka kod problema s učitavanjem DLL-ova, razumljivi putevi ispisa.
• Performanse: vrijeme pokretanja, operacije nad podacima, velike liste/izvještaji – mjeriti odvojeno pod emulacijom i nativno.
• Periferija: profili pisača, specijalni ispis, tijekovi rada skenera, funkcije pametne kartice.
• Sigurnost: interakcija EDR/AV, proxy/TLS, pohrana certifikata, rad s najmanjim privilegijama.

Važno je dokumentiranje: ako problem nastane zbog nedostajućih ARM64-drajvera, to nije „bugfix u Delphi“, već odluka o nabavi ili standardizaciji.

Operacije i podrška: kako integrirati ARM64 u svakodnevni rad

U praksi je važno koliko brzo se rješavaju slučajevi podrške. Za ARM64 isplati se proaktivno povećati podržanost:

Standardizirani profili uređaja i jasne dozvole

Definirajte podržane ARM64 modele ili barem minimalne profile (strategija drajvera, strategija ispisa, verzije Security-Agenta). „Radi na ARM64″ bez takvog okvira vodi ka neujednačenim okruženjima i time teško reproducibilnim kvarovima.

Mogućnost dijagnostike u aplikaciji

Čak i bez fokusa na razvoj, korisno je zahtijevati od softvera jasnu dijagnostiku: stranica s informacijama o sustavu koja prikazuje arhitekturu (x64 emulirano vs. ARM64 nativno), važne putanje, verzije ključnih komponenti i konfiguraciju ispisa značajno smanjuje vrijeme podrške. To nije „nice to have“, već operativna higijena.

Licenciranje i Dongles

Ako su u igri hardverski dongleovi ili stariji drajveri za licence, ARM64 brzo postaje kritičan. U mnogim okruženjima smisleno je prebaciti licenciranje na mrežno ili server-side mehanizme. Time se smanjuje ovisnost o drajverima na krajnjim uređajima i flota postaje zamjenjivija.

Što to znači za vašu Delphi-strategiju?

Delphi je u poslovnom kontekstu često stabilna komponenta za desktop klijente i servise. Windows 11 ARM64 nije argument „protiv Delphi“, već argument za čistiju kapsulaciju ovisnosti i za operativno orijentiranu modernizaciju: manje lokalnih specijaliziranih drajvera, manje in‑process komponenti, jasnija sučelja, bolje deployment.

Ako ste već danas na putu modernizacije (npr. BDE-zamjena, prelazak na 64‑bit, jača integracija REST, konsolidirani pristup podacima s FireDAC), tada je ARM64 često „samo“ dodatna ciljna točka koja oštri prioritete. Ako vaša aplikacija pak uvelike ovisi o starim drajverima, proprietarnim DLL-ovima i posebnim konfiguracijama radnih mjesta, ARM64 je smislen povod da se ti rizici učine transparentnima i planski smanje.

Zaključak: ARM64 je manje projekt portiranja nego arhitekturni i operativni projekt

Za tvrtke je Windows 11 ARM64 prije svega pitanje platforme u nabavi, sigurnosti i podršci. Za poslovni softver baziran na Delphi uspjeh se ne mjeri opcijom kompajlera, nego lancem drajvera, DLL-ova, COM-integracija, pristupa podacima i procesa ažuriranja. Pouzdan pristup je: najprije učiniti vidljivima ovisnosti i operativne putove, zatim testirati s pilot‑uređajima, potom ciljano razdvojiti komponente i profesionalizirati deployment – te isporučiti native ARM64 buildove tamo gdje dugoročno donose korist i stabilnost.

Ako želite uvesti Windows 11 ARM64 u vašoj floti i pritom planski osigurati Delphi-aplikacije, periferiju i sučelja, razgovarajte s nama o strukturiranoj inventuri i realnom putu migracije:

U stručnom okruženju također važnu ulogu igraju Delphi ARM64 Windows i X64-emulacija Windows 11, kada integracije, tokovi podataka i daljnji razvoj moraju čvrsto međusobno surađivati.

Razgovarajte o projektu ili planu modernizacije s Net-Base.