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

Windows-uređaji s ARM64-CPU (ARM64 je 64‑bitna arhitektura procesora, poznata iz mobilnih SoC-ova i sve češće i iz poslovnih prijenosnih računala) u mnogim tvrtkama više nisu samo „egzotika“. Dolaze kroz standardizirane flote prijenosnika, dulje trajanje baterije, nove sigurnosne funkcije u hardveru i stratešku diversifikaciju lanca opskrbe. Najkasnije kada poslovne jedinice nabavljaju nove uređaje ili OEM-i određene modele nude samo kao Windows na ARM, za IT‑odgovorne postavlja se praktično pitanje: Kako se ponaša naš Delphi-temeljeni poslovni softver pod Windows 11 ARM64 – i kako osiguravamo rad, podršku i daljnji razvoj?

Ključna stvar je: Windows 11 ARM64 s Delphi u tvrtkama nije toliko pitanje razvoja koliko pitanje ovisnosti, strategija deploya, drajvera, sučelja i stvarnog ponašanja na terenu. U praksi postoje tri pristupa: nastavak rada preko emulacije, native ARM64 buildovi ili prijelazni model koji kontrolirano smanjuje rizike. Ovaj članak razvrstava tipične zapreke i pokazuje održiv put koji funkcionira u IT‑planiranju, rolloutu i radu – bez „Sve ispočetka“-refleksa.

Zašto Windows 11 ARM64 sada postaje relevantan

Windows na ARM nije nova pojava, ali su se okvirni uvjeti promijenili: uređaji su dostupni u poslovnom okruženju, Windows 11 donosi znatno zreliju x64-emulaciju, a proizvođači softvera sve češće isporučuju ARM64 varijante. Za tvrtke to znači: ARM64 se ne pojavljuje kao jednokratan pilotski projekt, već kao platforma koja ulazi u planove nabave i životne cikluse.

Za softverska rješenja povezana s procesima manje je problem sama CPU, a više realnost periferije i integracija: pisači, kartice za potpis, skeneri, Office dodaci, COM-komponente (COM je Microsoftov model komponenti za integraciju aplikacija i biblioteka), proširenja ljuske, VPN-klijenti ili sigurnosni agenti. Ako nešto od toga nije kompatibilno s ARM64, nastaje potreba za podrškom – i često se tada za to okrivljuje „aplikacija“.

Razvrstavanje: Š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-zamjena s nativnom vezom, Delphi-ov sloj za pristup podacima) i mješavinom lokalnih i udaljenih integracija. Pod Windows 11 ARM64 pojavljuju se tri načina izvođenja:

1) Native ARM64-izvedba

Aplikacija i sve native biblioteke (DLL-ovi) dostupne su kao ARM64. To je dugoročno najsistematičnija opcija jer omogućava predvidivu izvedbu i stabilnost te izbjegava ograničenja emulacije. Međutim realno je samo ako se sve native ovisnosti prilagode: upravljački programi za baze podataka, ispis/pregled, PDF‑engine, kriptobiblioteke, OCR/Scan SDK‑ovi, upravljački programi za hardverske dongle‑ove itd.

2) x64-emulacija pod Windows 11 ARM64

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

3) Hybrid: ARM64-Client, x64-Komponenten entkoppeln

Put prijelaza je izvlačenje kritičnih x64-komponenti iz procesa: npr. kao eksterni servis, kao REST-backend (REST je HTTP-bazirani model sučelja) ili kao zaseban pomoćni program. To je manje elegantno nego „sve nativno“, ali često najisplativija ruta za osiguranje rada i postupnu modernizaciju ovisnosti.

Windows 11 ARM64 mit Delphi in Unternehmen: Die typischen Abhängigkeiten, die über Erfolg entscheiden

U projektima se brzo pokaže: usko grlo nije GUI, nego ekosustav. Strukturirana analiza ovisnosti uštedi ovdje tjedne pokušaja i pogrešaka.

Native DLLs und SDKs: Das unsichtbare Risiko

Mnoge Delphi-aplikacije povezuju DLL-ove trećih strana: generiranje PDF-a, Barcode/QR, obrada slika, šifriranje, proprietarne komunikacijske biblioteke. Pod ARM64 strogo vrijedi: DLL mora odgovarati arhitekturi procesa. Emulacija pomaže samo ako je cijeli proces x64. Čim se želići nativno izvršavanje, te biblioteke moraju postojati kao ARM64 ili biti zamijenjene.

Praktični savjet za IT: zatražite od odgovorne osobe za softver popis koji DLL-ovi leže u instalacijskom direktoriju i koji se učitavaju putem sistemskih putanja. To je temelj za procjenu spremnosti proizvođača i alternativnih rješenja.

COM, Office-Automation und Shell-Erweiterungen

COM se u svakodnevnom radu u poduzećima često koristi, a da to nije eksplicitno naznačeno: integracija s Outlookom, izvoz u Excel preko automatizacije, DMS-klijenti, preview-handleri u Exploreru, proširenja kontekstnog izbornika. Problem pod ARM64 nije toliko sam COM, koliko povezanost bitnosti: In-Process-COM-serveri (COM-komponente bazirane na DLL-ovima) moraju imati istu arhitekturu. Out-of-Process-COM (serveri bazirani na EXE) je fleksibilniji jer može raditi u zasebnom procesu.

Ako vaša Delphi-aplikacija, npr., koristi staru 32‑bitnu ili 64‑bitnu COM-DLL, to je pri nativnom ARM64-izvršavanju blocker. Emulirano kao x64 može raditi — pod uvjetom da su sve COM-ovisnosti također x64 i da se ne umeću dijelovi koji postoje samo za ARM64.

Druck, PDF und Treiberlandschaft

Problemi s ispisom su klasik pri promjenama platforme. Kod Windows 11 ARM64 presudno je ima li proizvođač pisača ARM64-vozače ili se mogu koristiti Universal Print/IPP-klasni vozači (IPP je standardizirani protokol ispisa). Također PDF-pisači, skupni ispis, ispis etiketa i specijalni uređaji (npr. termalni pisači) mogu ovisiti o vozačima koji postoje samo za x64.

Za IT-upravu i administraciju važna posljedica je: ARM64-rollouti moraju se uskladiti sa strategijom ispisa. „Aplikacija ne ispisuje“ često znači „vozač ne postoji“ ili „ispisni pipeline je drugačiji“.

Datenzugriff: FireDAC, ODBC/OLE DB und Datenbank-Clients

Na razini podataka isplati se jasna razdvojenost između protokola i klijentske biblioteke. BDE-Ablosung mit nativer Anbindung može, ovisno o bazi podataka, raditi s nativnim clientlibs ili s driverima. Ako je npr. potreban Oracle-Client, stariji PostgreSQL-Client ili specifičan ODBC-treiber, mora postojati u verziji za ARM64 – ili se oslonite na arhitekturu koja pristup podacima kapsulira na serverskoj strani (npr. preko REST-servisa ili jednog Windows-/Windows- und Linux-Services).

Za stabilan rad to je ključna poluga: što je manje desktop-klijent izravno vezan za upravljačke programe baze podataka i lokalne baze podataka „stackove“, to je lakše za ARM64. To vrijedi i u smislu sigurnosti: pristupne podatke baze, certifikate i mrežna pravila lakše je konzistentno upravljati na serverskoj strani.

Krypto, Smartcards, Signaturen, VPN, EDR

Mnogi poslovni procesi danas ovise o kriptografskim komponentama: S/MIME, klijentski certifikati, smartcard-middleware, kartice za potpis, TLS-Inspection u proxyjima. Tu su i rješenja za sigurnost krajnjih točaka (EDR je Endpoint Detection and Response) i VPN-klijenti. Te komponente moraju biti kompatibilne s ARM64, inače nastaje problem „uređaj je tu, ali mu nije dopušten pristup mreži“.

Za Delphi-aplikaciju to znači: ako koristite certifikate iz Windows-storea ili TLS preko sistemskih komponenti, to je obično manje kritično nego kada neka specifična third-party KryptodLL sjedi u procesu.

Entscheidungsmatrix: Emulation oder native ARM64-Portierung?

Poduzećima treba odluka koja odražava realnost podrške i životnog ciklusa. Jednostavno da/ne pitanje („Portieren wir?“) rijetko je korisno. Bolje je imati matricu koja ponderira ovisnosti i rizike:

• Čisti klijent sa standardnim Windows-API-jima (datoteke, mreža, ispis preko standardnih upravljačkih programa): emulacija može kratkoročno biti dovoljna; nativni ARM64 je srednjoročno ispravniji.
• Klijent s mnogo nativnih DLL-ova trećih strana (PDF, OCR, hardver): prvo provjeriti dostupnost, pa odlučiti. Često je smislen hibridni put.
• Klijent s COM-DLL-ovima / proširenjima ljuske: očekujte arhitektonske konflikte; razmotrite razdvajanje izvan procesa (Out-of-Process).
• Klijent s izravnom zbirkom DB upravljačkih programa: ili konsolidirati upravljačke programe ili premjestiti pristup podacima u servise.
• Visoka regulacija/Signatur/Smartcard: rano verificirajte ARM64-sposobnost sigurnosnog i middleware lanca.

Važno: emulacija nije „druga klasa“, ali je operativni rizik ako dugoročno planirate uređaje ARM64 u floti. Najkasnije pri većim ažuriranjima, promjenama upravljačkih programa ili promjenama sigurnosnih agenata ne želite ostati zaglavljeni u lancu iznimaka.

Ein belastbarer Migrationspfad: Von heute nach ARM64 ohne Big Bang

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

Schritt 1: Bestandsaufnahme mit „Betriebsbrille“

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

• Koje klase uređaja: prijenosna računala, Rugged Devices, terminali?
• Koja periferija: pisači, skeneri, čitači kartica, labeleri?
• Koje integracije: Office, DMS, ERP, lokalne usluge, komponente preglednika?
• Koji oblik instalacije: MSI, Setup-EXE, ClickOnce, ručna instalacija?
• Koja prava: trebaju li administratorska prava, lokalne usluge, pravila vatrozida?

Ovaj pregled brzo otkriva 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 putove: ispis u svim varijantama, izvoz/uvoz, potpisivanje, offline/online, ažuriranja, prebacivanje tenanta, proxy/VPN scenariji. Dokumentirajte odstupanja kao operativne incidente, ne kao programerske greške. Tako ostaje prioritizacija čista.

Korak 3: Smanjiti ovisnosti – prvo one s najvećim utjecajem na podršku

Tipične mjere koje u svakodnevnom radu donose puno:

• Standardizirati PDF-/put ispisa: udaljiti se od vlasničkih DLL-ova pisača prema stabilnim, testiranim pipelinama.
• Razdvojiti Office-integraciju: umjesto In-Process dodataka radije provjeriti formate izvoza i serversko generiranje dokumenata.
• Konsolidirati pristup bazi podataka: definirani put preko drajvera umjesto „ODBC ovisno o radnom mjestu“.
• Kapsulirati povezivanje hardvera: po mogućnosti preko eksternih procesa/usluga koje se mogu zasebno ažurirati.

Korak 4: Modernizirati deployment i sposobnost ažuriranja

ARM64 je dobar povod za raščlanjivanje instalacije i ažuriranja. Za poduzeća ovdje nisu presudne značajke, već mogućnost rollbacka, reproducibilnost i usklađenost s politikama. Provjerite:

• Pakiranje: MSI vs. MSIX (MSIX je Microsoftov moderni format pakiranja aplikacija s čistom instalacijom/deinstalacijom i potpisom).
• Potpisivanje: Code Signing (digitalni potpis EXE/DLL) smanjuje trenja sa SmartScreen-om i EDR-om te je relevantno za kontrolirana uvođenja.
• Upravljanje konfiguracijom: razdvajanje programskih datoteka i konfiguracije, jasne staze, bez „skrivenih“ ovisnosti o Registryju.
• Kanali ažuriranja: Pilot, Ring 1, Ring 2 – s telemetrijom/logiranjem na razini aplikacije i na razini operacija.

Korak 5: Native ARM64 tamo gdje se to stvarno isplati

Native ARM64-buildovi smisleni su kada (a) imate kontrolu nad ovisnostima i (b) aplikaciju dugoročno želite dalje razvijati. Tipično se isplati za centralne klijentske aplikacije koje mnogi korisnici svakodnevno koriste i koje ionako modernizirate. Za rijetko korištene alate x64-emulacija može biti prihvatljiv prijelaz, pod uvjetom da podrška i sigurnost prate.

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

Mnoge Delphi-okoline povijesno su narasle kao „dicker Client“. To funkcionira, ali veže operacije i ažuriranja snažnije za pojedinačne konfiguracije radnih mjesta. ARM64 čini vidljivim gdje ta sprega postaje skupa. Pragmatičan korak modernizacije često zato nije „UI novo“, već sučelja novo.

Više stabilnosti kroz serverske odgovornosti

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

• jedinstvene verzije drajvera i biblioteka,
• bolje kontroliranu sigurnost (certifikati, tajne, mreža),
• manju složenost na klijentu (ARM64, x64, u budućnosti i druge platforme),
• jasnije točke za monitoring i logiranje.

Za IT-odlučitelje to je stvarna prednost u radu: problemi se na strani poslužitelja brže reproduciraju, umjesto da ostanu „na nekom posebnom laptopu“.

REST-API kao sloj za odvajanje

REST-API nije automatski „moderan“, ali je robusno riješenje za odvajanje između klijenata i backenda. Jasno definira koje su podatke i akcije dozvoljene te se može sigurno zaštititi (npr. putem tokena, certifikata ili SAML 2.0 kao standarda identiteta u korporativnim okruženjima). Za ARM64 to znači: klijent ne mora nositi toliko „svjetskog znanja“ o bazama podataka, upravljačkim programima i mrežnim detaljima.

I ako ne prebacite sve odjednom: već mali, dobro ograničeni API-modul (npr. generiranje dokumenata, provjera licenci, usklađivanje osnovnih podataka) može ukloniti ovisnosti iz klijenta i time smanjiti rizike vezane uz ARM64.

Test i kvaliteta: Što trebate drugačije provjeravati za ARM64

Mnogi timovi testiraju desktop-softver prvenstveno funkcionalno. Za ARM64 trebate više fokusirati operativno testiranje, jer su obrasci pogrešaka drugačiji: ne „pogrešan izračun“, nego „komponenta se ne učitava“, „nedostaje upravljački program“, „ažuriranje ne uspijeva“, „Office-integracija se ruši“.

Kontrolna lista za prihvat u ARM64-okruženju

• Instalacija/Deinstalacija: čista, bez ostataka i bez improvizacija koje zahtijevaju administratorske intervencije.
• Put ažuriranja: nadogradnja preko više verzija, scenarij rollbacka, provjera potpisa.
• Logging: centralni logovi, jasni kodovi pogrešaka kod problema s učitavanjem DLL-ova, dokumentirani putovi ispisa.
• Performanse: vrijeme pokretanja, operacije nad podacima, velike liste/izvještaji – mjeriti odvojeno u emulaciji i nativno.
• Periferija: profili pisača, specijalni ispis, tijekovi rada skenera, funkcije pametnih kartica.
• Sigurnost: interakcija EDR/AV, proxy/TLS, spremište certifikata, rad po principu najmanjih privilegija.

Važna je dokumentacija: ako problem nastane zbog nedostajućih ARM64-upravljačkih programa, to nije „Bugfix in Delphi“, nego odluka o nabavci ili standardizaciji.

Operacija i podrška: Kako integrirati ARM64 u svakodnevni rad

U svakodnevnom radu broj jedan je koliko brzo se rješavaju slučajevi podrške. Za ARM64 se isplati proaktivno povećati mogućnost podrške:

Standardizirani profili uređaja i jasna odobrenja

Definirajte podržane ARM64 modele ili barem minimalne profile (strategija upravljačkih programa, strategija ispisa, verzije security-agenta). „Radi na ARM64“ bez tih okvira vodi u neujednačena okruženja i time do teško reproducibilnih smetnji.

Sposobnost dijagnostike u aplikaciji

Čak i bez developerskog fokusa, ovdje je smislen jasan zahtjev prema softveru: stranica s informacijama o sustavu koja navodi 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 dongle-i

Ako su u igri hardverski dongle-ovi ili stariji upravljački programi za licence, ARM64 brzo postaje kritičan. U mnogim okruženjima smisleno je prebaciti licenciranje na mrežno ili serversko rješenje. Time se smanjuje ovisnost o upravljačkim programima na krajnjim uređajima i flota postaje zamjenjivija.

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

Delphi je u korporativnom kontekstu često stabilna komponenta za desktop-klijente i servise. Windows 11 ARM64 nije argument „protiv Delphi“, ali je argument za jasniju kapsulaciju ovisnosti i za operativno orijentiranu modernizaciju: manje lokalnih specijaliziranih upravljačkih programa, manje komponenti unutar procesa, jasnija sučelja, efikasnije postavljanje (deployment).

Ako ste danas već na putu modernizacije (npr. BDE-zamjena, prijelaz na 64‑bit, intenzivnija REST-integracija, konsolidirani pristup podacima s FireDAC), onda je ARM64 često „samo“ dodatna meta koja izoštrava prioritete. Ako vaša aplikacija pak znatno ovisi o starim upravljačkim programima, proprietarnim DLL-ovima i posebnim konfiguracijama radnih mjesta, ARM64 je opravdan povod da te rizike učinite transparentnima i planirano ih smanjite.

Zaključak: ARM64 je manje projekt portiranja, a više arhitekturni i operativni projekt

Za poduzeća je Windows 11 ARM64 prije svega pitanje platforme u nabavi, sigurnosti i podršci. Za poslovni softver baziran na Delphi uspjeh se ne odlučuje opcijom kompajlera, nego lancem upravljačkih programa, DLL-ova, COM-integracija, pristupa podacima i procesa ažuriranja. Pouzdan put je: prvo učiniti ovisnosti i operativne tokove vidljivima, zatim testirati s pilotnim uređajima, potom ciljano razdvojiti i profesionalizirati proces postavljanja – i isporučiti native ARM64-buildove ondje gdje dugoročno donose korist i stabilnost.

Ako želite uvesti Windows 11 ARM64 u svoju flotu i pri tom planirano osigurati Delphi-aplikacije, periferiju i sučelja, razgovarajte s nama o strukturiranom pregledu stanja i realističnom putu migracije:

U stručnom okruženju također važnu ulogu igraju Delphi ARM64 Windows i X64-Emulation Windows 11 kada integracije, tokovi podataka i daljnji razvoj moraju usklađeno funkcionirati.

Razgovarajte o projektu ili modernizacijskom zahvatu s Net-Base.