Rano planirajte Windows 11 ARM64 za Delphi-aplikacije

Windows 11 ARM64 više nije rijedak slučaj za tehnološke entuzijaste u B2B svakodnevici. Nove generacije prijenosnika, dulje trajanje baterije, „Always-on“ scenariji i rastuća potražnja za laganim, mobilnim radnim mjestima dovode do toga da tvrtke kupuju ARM64-klijente – ponekad namjerno, ponekad usput kroz standardne modele u okvirnom ugovoru. Za timove s postojećim prilagođenim softverom to je jasna poruka: ARM64 mora rano u tehničko planiranje, inače će kasnije postati skupi projekt naknadne opreme.

Kod Delphi-aplikacija središnje pitanje rijetko glasi „može li Delphi to kompilirati?“. U praksi ARM64-rolloutovi gotovo uvijek zapnu na periferiji: na nativnim DLL-ovima, komponentama za ispis/skeniranje, upravljačkim programima za baze podataka, report-engines, COM-integracijama, setup-rutina, code-signingu ili build-pipelines koje implicitno poznaju samo x64. Upravo zato se isplati tretirati Windows 11 ARM64 kao zahtjev za arhitekturu i operacije – ne kao čisto platformsku značajku.

Ovaj članak prikazuje koji se tehnički zapreke tipično pojavljuju kod Delphi, kako sustavno identificirati rizike i koje su pragmatične migracijske putanje provjerene – od postupnog prilagođavanja pojedinih modula do jasne ciljane arhitekture sa servisima i REST-serverima.

Zašto je Windows 11 ARM64 sada tema arhitekture

U mnogim tvrtkama „Windows“ je dugo značilo x86/x64. To predpostavka živi u skriptama, installerima, komponentama trećih strana, pa ponekad i u modelu podataka (npr. putanje, registry-ključevi, sučelja upravljača). Čim se pojave ARM64-klijenti, postane vidljivo koliko implicitnog znanja sustav sadrži. I upravo je to gospodarski bitno: kasne prilagodbe nisu samo „nekoliko kompajlerskih flagova“, već čišćenje pretpostavki koje su se godinama ukorijenile.

Praktično je ARM64 posebno relevantan u trima situacijama:

• Klijentski softver s dugim vijekom trajanja: strukturne aplikacije koje se koriste 8–15 godina i iterativno proširuju. Nova klijentska platforma usred životnog ciklusa vjerojatnija je nego potpuni novi razvoj.
• Mješovite flote: terenski servis, upravljački prijenosnici, BYOD-slični scenariji ili podružnice koje nabavljaju drugu hardver.
• Pritisak na sigurnost i usklađenost: moderni code-signing, hardening, „least privilege“, kontrolirani updateri – pri tome se ionako prodiru instalacijski i update procesi. Tada je povoljno ugraditi ARM64 kao popratni zahtjev.

Dobra vijest: tko ionako radi na Delphi Modernisierung, prelasku na 64-bit, razdvajanje pristupa podacima ili ciljanoj arhitekturi orijentiranoj na servise, često može „povući“ i Windows 11 ARM64 – pod uvjetom da stoji rano u backlogu, a ne tek kad prva ARM-strojica dođe u support.

Delphi na ARM64: što je „lako“, što je „teško“?

Delphi-projekti se jako razlikuju: od čistih VCL-desktop klijenata do višeslojnih sustava s REST-serverima, Windows servisima, report-workerima, integracijskim komponentama i pozadinskim jobovima. Za Windows 11 ARM64 presudno je koje dijelove zaista treba nativno pokretati na klijentu, a koje je ionako smisleno izdvojiti u servise.

Kompatibilnost kompajlera rijetko je glavni problem

Ako je vlastiti kod uredan (bez inline-assemblera, bez starih 32-bitnih pretpostavki, bez fragilnih pointer-castova, bez zastarjelih API poziva), kompilacija za novu ciljanju platformu često je izvediva. Problemi nastaju zbog:

• Komponenti trećih strana s nativnim dijelovima (DLL-ovi, BPL-ovi, C/C++-bridgeovi)
• Upravljača i povezivanja uređaja (ispis, skeniranje, potpisne ploče, dongleovi)
• Pristupa bazama podataka preko ODBC/OLE DB/klijentskih biblioteka koje nisu ARM64-kompatibilne
• Reporting i Office-integracija (COM-automatizacija, stari export-filteri)
• Installer/Updater koji testiraju samo x64 ili koriste čvrsto ugrađene putanje

Time je Windows 11 ARM64 prije svega „ekosustavni test“: koliko je vaš softverski paket odvojen od starih platformskih pretpostavki?

VCL, FMX i UI-ovisnosti

Mnoge B2B-strukovne aplikacije bazirane su na VCL-u i koriste godinama narasle UI-komponente. To nije nužno problem – ali UI je često mjesto gdje se ovisnosti gomilaju: PDF-printeri, generatori barkoda, biblioteke za obradu slika, browser-controli, COM-objekti. Za ARM64 vrijedi: što više UI-bliskih specijalnih komponenti koristite, to je važnija rana lista kompatibilnosti.

Kod multiplatformskih strategija (npr. Windows + macOS) često se koristi FMX. Neovisno o frameworku, robusna strategija je odvojiti poslovnu logiku i integracije od UI-a. To donosi korist i za Delphi Multiplattform i za Windows 11 ARM64.

Tipične tehničke zapreke (i kako ih rano prepoznati)

U praksi se većina ARM64-problema može rano prepoznati ako strukturirano inventarizirate i provedete „ARM64 Readiness“-check. Ključno je ne gledati samo Delphi-kod, već sve što proizvod čini: instalere, drivers, konfiguraciju, pluginove, alate trećih strana, update-lanac, support-skripte.

1) Nativne DLL-ove, BPL-ove i mješovite procesne krajolike

Mnoge Delphi-aplikacije učitavaju dodatne DLL-ove: kriptografiju, CAD-viewer, OCR, potpis, hardware-SDK-ove, specijalne parsere. Na x64 se često implicitno pretpostavlja da postoji „64-bit DLL“. Za ARM64 je drugačije: trebate eksplicitno ARM64-binarije ili arhitekturu koja tu ovisnost uklanja s klijenta.

Praktičan pristup:

• Sastavite listu svih učitanih nativnih modula (uključujući indirektne preko komponenti).
• Klasificirajte: „ARM64 dostupan“, „x64-only“, „32-bit-only“, „nejasno“.
• Procijenite mora li modul zaista biti lokalno ili se može izdvojiti u servis.

Čest nalaz: jedan x64-only modul blokira cijeli ARM64-klijent. Tad postaje ekonomski opravdana čista slojevita ili Layer-3 Architektur: UI/klijent ostaje lagan, integracije migriraju u kontrolirane serverske/servisne slojeve.

2) COM, Office-automatizacija i Shell-integracije

U mnogim tvrtkama Word/Excel-export, Outlook-integracija, kontekstni izbornik Explorera ili DMS-integracije povijesno su izvedene preko COM-a. COM nije automatski „ARM64-ready“, posebno ako COM-serveri trećih strana ili add-ini postoje samo u x64 verziji. Također, rad s mješavinom 32-bit/64-bit (Out-of-Proc vs. In-Proc) brzo postaje kompleksan.

Rana provjera:

• Koji se COM-objekti koriste (ProgIDs/CLSID lista)?
• In-Proc ili Out-of-Proc? Postoje li ARM64-registracije?
• Može li se export riješiti serverskim bibliotekama (npr. formati temeljeni na dokumentima) umjesto Office-automatizacije?

Često je to poluga modernizacije: udaljavanje od UI-povezane automatizacije prema reproducibilnim export-servisima (npr. PDF/Excel preko biblioteka) koji su primjenjivi i za Windows x64 i za ARM64 ili čak Linux-servere.

3) Pristup bazama podataka: ODBC, klijentske biblioteke, legacy-BDE

Pristup podacima često je ARM64-graničnik jer tu upravljačka krajolika i klijentske biblioteke igraju ulogu. Posebno kritični su stari ODBC-setupi, proprietarni DB-klijenti ili lokalne baze s povijesnim pristupnim slojevima.

Za Delphi-stogove to je klasika: ako su još Borland BDE, stare Paradox-strukture ili teško održive lance upravljača uključenI, ARM64 postaje katalizator. BDE-ablösung i prelazak na BDE-Ablösung mit nativer Anbindung s jasnom DB-driver strategijom značajno smanjuju platformne rizike.

Konkrektni provjerni punktovi:

• Koje DB-e koristite (SQL Server, PostgreSQL, MariaDB, Firebird, lokalni enginei)?
• Koje drivere upotrebljavate (ODBC, native client, BDE-Ablosung mit nativer Anbindung-driveri, OLE DB)?
• Gdje su connection-stringovi i DSN-ovi (po korisniku, po stroju, u installeru)?
• Postoje li ovisnosti o 32-bit ODBC-driverima ili starim providerima?

Posebno kod SQL Server/ODBC, ARM64-klijent može raditi – ali samo ako je lanac drivera i instalacijska rutina uredna. To nije tema koju želite debugirati „u polju”.

4) Reporting, ispis, skeniranje, PDF i output-workflowi

Output u strukovnim aplikacijama često je poslovno kritičan: otpremnice, etikete, računi, zapisnici, očitanja brojila, certifikati, shipping-labeli. Mnogi od tih workflowa ovise o reporting-komponentama ili specifičnim driverima za pisače/skenere.

Na Windows 11 ARM64 tipične zapreke su:

• Driveri za etikete/specijalni pisači dostupni samo kao x64
• Scanner-softver/SDK bez ARM64-supporta
• Stari report-enginesi s nativnim preview-/export modulima
• Generiranje PDF-a preko „virtualnih pisača“ umjesto biblioteke

Robustan pristup je standardizirati output-workflowe: generirati PDF/Office-formate preko biblioteka, ispis preko standardiziranih sučelja, kapsulirati pristup specifičnom hardveru. Gdje to nije moguće, treba rano sastaviti matricu uređaja/drivere za ARM64.

5) Installer, Updater, Code-Signing i operacije

Mnogi ARM64-projekti ne zapnu na programu, već na isporuci: setup pogrešno prepoznaje arhitekturu, ne instalira drivere, ne registrira COM, postavi pogrešne putanje ili padne na zahtjevima za code-signing. I automatski update-i (delta-updatei, self-updateri) često su jako ovisni o arhitekturi.

Važna operationalna pitanja:

• Kako se instalira (MSI, Inno Setup, vlastiti updater)?
• Kako se instaliraju ovisnosti (VC++ runtimes, drivere, certifikati)?
• Kako se signira (EXE, DLL, installer, paket drivera)?
• Kako se testira: prava ARM64-hardware ili samo pretpostavke?

Za tvrtke je to governance-tema: ako se Windows 11 ARM64 pojavi u klijentskoj floti, deployment mora biti reproducibilan – uključujući rollback, supportabilnost i jasnu verzioniranost.

Strategija: Windows 11 ARM64 kao „rana nefunkcionalna zahtjev“

Gospodarski razumna metoda je tretirati ARM64 kao nefunkcionalni zahtjev (NFA) – slično kao performanse, sigurnost ili offline-sposobnost. To znači: ne čekati u sprintu „ako zatreba“, već definirati ga kao vodilju za arhitekturu i lanac isporuke.

ARM64-Readiness-Check: inventar umjesto osjećaja

Pouzdan check obično obuhvaća:

• Inventar ovisnosti: sve komponente trećih strana, DLL-ovi, drivere, SDK-ovi, browser-controli, kriptomoduli, reporting.
• Analizu build-/pipeline: build-targeti, paketiranje, signiranje, pohrana artefakata, brojevi verzija, reproducibilnost.
• Installer-/update-lanac: logika setupa, prerequisiti, registry/putanje u datotečnom sustavu, politike, prava.
• Operativni model: support, logging, crash-dumpovi, telemetrija (ako postoji), plan rollouta.

Rezultat ne bi trebao biti samo „ARM64: da/ne“, već prioritetizirana lista: koji blokatori postoje, koji moduli su zahvaćeni, koje alternative postoje i kolika je realna investicija.

Matrica odluka: nativno na ARM64 ili depolirati?

Za svaku problematičnu ovisnost treba jasna odluka:

• Moguća ARM64-nativna zamjena: nadogradnja, promjena proizvođača, prelazak na drugu biblioteku.
• Ovisnost se može izdvojiti: npr. u Windows servis, background worker ili centralni REST-server.
• Ovisnost mora ostati lokalna: npr. jer je hardver direktno spojen na klijent. U tom slučaju trebaju obvezujuća ARM64 hardverska/driverska odobrenja.

Za integracije je često najčišći put izdvajanje: klijent ostaje UI + dijalozi, dok kompleksna integracijska logika radi u kontroliranim servisima. To pomaže i kod centralnih ažuriranja, modela prava i bolje testabilnosti.

Arhitekturni obrasci koji stabiliziraju ARM64-projekte

Ako se Windows 11 ARM64 planira rano, može se donijeti više arhitekturnih odluka tako da kasnije ne budu skupe za preinačiti.

1) Jasne slojevitosti: UI, poslovna logika, integracije, pristup podacima

Postarjeli Delphi-klijenti često imaju „sve u jednom procesu“: UI, poslovna pravila, pristup podacima, DMS-povezivanje, ispis i export. To je održivo dok platforma ostane stabilna. No čim postanu relevantne platformne varijante (ARM64, eventualno macOS, eventualno terminal server), vrijednost jasnog slojevitog dizajna raste.

Pragmatični cilj:

• UI-sloj: minimalan, testabilan, bez direktnih driver-/SDK-ovih ovisnosti.
• Poslovna logika: što više platformno neutralna, uredno modelirana.
• Integracijski sloj: kapsulira COM, formate datoteka, DMS/ERP-connectore, device-SDK-ove.
• Pristup podacima: konsolidiran (npr. FireDAC), jasne granice transakcija, bez rasutih SQL fragmenata.

To nije „akademska vježba“, već stvarna ušteda: ako je samo integracijski sloj problematičan za ARM64, ne morate graditi cijeli klijent iznova.

2) Servisi i REST-serveri kao stabilni oslonac

Mnogi B2B-sustavi imaju koristi ako centralne funkcije pokrenu kao REST-servere ili kao Windows-/ Linux-servise: provjera prava, dokumentworkflowi, validacija podataka, export, import, sučelja prema ERP/DMS/CRM. Ako ove funkcije rade serverski, kompleksnost na klijentu se značajno smanjuje – pa i ARM64-površina napada.

Tipične raspodjele koje se pokazale dobrima:

• Klijent: dialogi, prikaz, offline-logika (ako je potrebna), minimalne lokalne integracije.
• REST-server: funkcionalne operacije, validacija, multi-tenant podrška, centralno logiranje.
• Worker/Service: vremenski vođeni jobovi, polling sučelja, generiranje reporta, batch-exporti.

To se uklapa i u moderne operativne modele: funkcija koja radi serverski ažurira se jednom – umjesto na svakom ARM64-klijentu pojedinačno.

3) Jedan build-system, više targeta (x64 + ARM64) od početka

Ako je ARM64 cilj, build-pipeline to treba odražavati. Ne kao „napravit ćemo kasnije specijalni build“, već kao standard: svaki release-kandidat reproducibilno se gradi za x64 (i, ako je planirano, ARM64), uključujući signiranje i paketiranje installera.

Manje je važno koji se alati koriste, važna je dosljednost:

• Jasno imenovanje artefakata (arhitektura u nazivu paketa/strukturi mapâ).
• Odvajanje konfiguracijskih vrijednosti po targetu (putanje, prerequisiti, paket drivera).
• Definiranje smoke-testova po arhitekturi (start, login, DB-veza, ispis/PDF).

Tako ARM64 postaje ne „Big Bang“, već kontrolirani dodatan target.

Delphi-modernizacija: ARM64 kao prilika za ciljano smanjenje tehničkog duga

Mnoge tvrtke koriste nove platformne zahtjeve kao povod za „sve iz temelja“. To je rizično i često nepotrebno. Ekonomski smislenije je koristiti Windows 11 ARM64 kao vodilju za postupnu modernizaciju: rješavati tehnički dug tamo gdje blokira ARM64 ili ugrožava isporučivost.

64-bit i Unicode: ne skrivajte stare probleme

Ako baza koda još sadrži 32-bitne pretpostavke ili zaostatke iz ranih verzija Delphi, oni će se pri promjeni platforme ponovno pojaviti. Iako ARM64 ne znači automatski „Unicode“, mnogi projekti koji ozbiljno rade ARM64, u isto vrijeme osiguravaju da je Unicode uređen, da su 64-bit putanje uspostavljene i da su memorijske/pointer teme očišćene.

Cilj nije perfekcija, već pouzdan standard: kod koji se može graditi za nove targete bez ponovnog generiranja istih klasa pogrešaka.

BDE-Ablösung i konsolidirani pristup podacima kao ARM64-enabler

Gdje postoje povijesni pristupi podacima (BDE, lokalni Paradox-podaci, mješoviti pristupi), konsolidacija je poluga s višestrukim učinkom: održiviji kod, stabilniji deploymenti, jasnija strategija drivera. S FireDAC pristup se u mnogim scenarijima može unificirati, uključujući centralizirano upravljanje parametrima, strategije poolinga i uredno rukovanje greškama.

Važno: BDE-ablösung nije samo „zamjena komponente“. Utječe na transakcijsku logiku, tipove podataka, sortiranja, semantiku filtera i ponekad i na model podataka. Zato treba planirati – a ne reagirati kao hitnu mjeru kad ARM64-klijenti iznenada dođu na teren.

Testiranje i osiguranje kvalitete: ARM64 je planabilan samo ako je mjerljiv

Rano planiranje ARM64 znači i: mora se testirati – ne svaki feature u potpunosti, već ciljani test rizika kritičnog lanca. Najvažniji korak je imati stvarno ARM64 test okruženje. Emulacija ponekad pomaže, ali ne može zamijeniti praksu s pravim hardverom, stvarnim driverima i stvarnim sigurnosnim politikama.

Minimalni ARM64-smoke-test: što je doista rano potrebno pokriti

Pragmatičan, ali učinkovit skup smoke testova za svaki release-kandidat:

• Pokretanje programa, login, osnovne UI-funkcije
• DB-veza (uključujući autentikaciju, certifikate, DNS/Proxy ako je relevantno)
• Jedan ključni end-to-end proces (npr. kreirati nalog, spremiti, ispisati/eksportirati)
• Updater/Installer: nova instalacija i update preko verzija
• Logging/poruke o grešci: jesu li dijagnostike na ARM64 korisne?

Tako postaju tipični ARM64-blokatori rano uočljivi: nedostajuće DLL-ove, krivi driveri, problemi s setupom, neočekivani zahtjevi za pravima.

Kapacitet dijagnostike: crash-dumpovi, logovi, transparentnost verzija

Kad je ARM64 u floti, dolazit će support-primjeri – već zbog novih kombinacija drivera. Zato se isplati standardizirati dijagnostiku: jasne build-ID-e, informativne logove, reproducibilne instalacijske i update putanje. To nije specifično za ARM64, ali ARM64 brzo iskazuje nedostatke koji postaju skupi.

Rollout i operacije: mješovite flote bez kaosa

Većina tvrtki će srednjoročno imati mješovite klijentske flote: dio x64, dio ARM64. Ključ je svjesno oblikovati to stanje.

Paketiranje: odvojeni installer, jasna detekcija, jedinstveni download-kanali

U praksi najbolje funkcionira ako su installer/paketi jednoznačni: x64-paket je x64, ARM64-paket je ARM64. „Jedan installer za sve“ zvuči praktično, ali brzo postane kompleksan (provjerna logika, prerequisiti, driver-putanje, signiranje, popravna instalacija). Za kontrolirane enterprise-rolloute jednoznačnost je često robusniji pristup.

Strategija ažuriranja: bez posebnih staza za ARM64

ARM64 ne bi trebao biti posebna staza u update procesu. Cilj: ista frekvencija izdanja, isti broj verzije funkcionalnosti, ali odvojeni artefakti. Ako se ARM64 ažurira samo „ručno“, u floti nastaju razlike koje kasnije povećavaju troškove podrške.

Integracije uredno dokumentirane

Mnogo ARM64-problema nije u vlastitom kodu, već u integracijama: ERP-connector, DMS-klijent, signature-service, scanner-softver, driver za etikete. Održavana lista integracija s verzijama i arhitektonskim napomenama za B2B-sustave je ionako preporučljiva – i čini ARM64-odluke transparentnima.

Što tvrtke sada konkretno trebaju učiniti (bez akcionalizma)

Rano planiranje Windows 11 ARM64 ne znači odmah sve preurediti. Znači: postaviti prava pitanja rano i ukloniti blokatore dok je napor planabilan. Provjereni pristup je:

• 1) Inventar stanja (2–10 dana ovisno o veličini sustava): ovisnosti, installer, driveri, pristup podacima, COM, reporting.
• 2) Ciljno stanje i put: što mora biti nativno na klijentu? Što postaje servis/REST? Koje se komponente zamjenjuju?
• 3) Proof of Feasibility: radni ARM64-build s installerom i jednim end-to-end use-caseom.
• 4) Postupno jačanje: preostale funkcije, testovi, update-lanac, dijagnostika.

Tako ne nastaje „ARM64-projekt“ koji mjesecima radi izolirano, već kontrolirano proširenje isporučivosti.

Zaključak: Windows 11 ARM64 nije hipe, već rani indikator tehničke zrelosti

Windows 11 ARM64 za mnoge tvrtke postaje stvarnost – kroz nabavu hardvera, zahtjeve za mobilnošću ili standardizaciju. Za Delphi-aplikacije stvarni izazov nije samo izvorni kod, već cjelokupan sustav ovisnosti, instalacijskih i update procesa, integracija i drivera. Tko ARM64 planira rano, može te točke strukturirano razjasniti umjesto da ih kasnije pod vremenskim pritiskom „patcha“.

Na kraju je ARM64 koristan test: koliko je vaša aplikacija odvojiva, testabilna i isporučiva? Ako na to pitanje odgovorite sada, ne dobivate samo dodatne opcije platformi, već i stabilniju osnovu za modernizaciju, servise, REST-arhitekture i dugoročnu održivost.

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.