Rano planirajte Windows 11 ARM64 za Delphi aplikacije

Windows 11 ARM64 više nije u B2B-svakodnevnici samo izuzetak za tehničke entuzijaste. Nove generacije prijenosnika, duže trajanje baterije, scenariji „Always-on“ i sve veća potražnja za laganim, mobilnim radnim mjestima dovode do toga da preduzeća nabavljaju ARM64‑klijente – ponekad svjesno, ponekad usput kroz standardne modele u okvirnom ugovoru. Za timove sa zrelim prilagođenim softverom to je jasna poruka: ARM64 mora rano u tehničko planiranje, inače će kasnije postati skupi projekat naknadne prilagodbe.

U Delphi-aplikacijama centralno pitanje rijetko glasi „može li Delphi to kompajlirati?“. U praksi ARM64-rollout gotovo uvijek zakaže na periferiji: na nativnim DLL-ovima, komponentama za štampanje/skeniranje, drajverima za baze podataka, report‑engineima, COM‑integracijama, setup‑rutinama, code‑signingu ili u build‑pipelineima koji šutke poznaju samo x64. Upravo zato se isplati tretirati Windows 11 ARM64 kao arhitektonsko i operativno zahtjev — a ne kao puki feature platforme.

Ovaj članak pokazuje koje tehničke zamke se kod Delphi tipično pojavljuju, kako sistematski identificirati rizike i koji pragmatični migracioni putevi su se pokazali efikasnim — od postupnog pripremanja pojedinih modula do jasne ciljane arhitekture sa servisima i REST‑serverima.

Zašto je Windows 11 ARM64 sada arhitektonska tema

U mnogim organizacijama „Windows“ je dugo značilo x86/x64. Ovo pretpostavka je ugrađena u skripte, instalere, third‑party komponente i ponekad čak i u model podataka (npr. putanje, Registry‑ključeve, drajverske interfejse). Čim se pojave ARM64‑klijenti, postane vidljivo koliko implicitnog znanja je u sistemu. I upravo je to suština sa stanovišta ekonomije: kasne prilagodbe nisu samo „nekoliko kompajlerskih flagova“, nego čišćenje pretpostavki koje su se taložile godinama.

Praktično, ARM64 postaje relevantan naročito u tri situacije:

• Klijentski softver s dugim životnim ciklusom: Stručne aplikacije koje se koriste 8–15 godina i iterativno se nadograđuju. Nova klijentska platforma usred životnog ciklusa je vjerojatnija od potpunog ponovnog razvoja.
• Mješovite flote: terenski servis/servisne ekipe, management‑prijenosnici, BYOD‑slični scenariji ili kćerke firme koje nabavljaju drugu opremu.
• Pritisak sigurnosti i usklađenosti: moderni code‑signing, hardening, princip najmanjih privilegija, kontrolisani updateri — pri čemu se instalacijski i update procesi ionako dotiču. Upravo tada je povoljno integrisati ARM64 kao sporedni zahtjev.

Dobra vijest: Ko radi već na Delphi Modernizaciji, prelasku na 64‑bit, razdvajanje pristupa podacima ili na servisno orijentiranu ciljnu arhitekturu, često može „povesti“ i Windows 11 ARM64 — pod uslovom da je to rano u backlogu, a ne tek kad prva ARM‑mašina stigne u podršku.

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

Delphi‑projekti se vrlo razlikuju: od čistih VCL desktop‑klijenata do višeslojnih sistema sa REST‑serverima, Windows servisima, report‑workerima, integracijskim komponentama i background jobovima. Za Windows 11 ARM64 je odlučujuće koje dijelove stvarno mora nativno pokretati klijent i koje dijelove je ionako smisleno izbaciti u servise.

Kompajler rijetko predstavlja glavni problem

Ako je vlastiti kod čist (nema inline‑assemblera, starih 32‑bit pretpostavki, fragilnih pointer‑castova, zastarjelih API‑poziva), kompajliranje za novu ciljnu platformu je često izvedivo. Problemi nastaju zbog:

• Third‑party komponenti sa nativnim dijelovima (DLL‑ovi, BPL‑ovi, C/C++ mostovi)
• Drajveri i povezivanje uređaja (štampa, skeniranje, potpisni paneli, dongle‑ovi)
• Pristup podacima preko ODBC/OLE DB/klijentskih biblioteka koje nisu ARM64‑kompatibilne
• Reporting i Office‑integracija (COM‑automation, stari export filteri)
• Installer/Updater koji testiraju samo x64 ili koriste hardkodirane putanje

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

VCL, FMX i UI‑zavisnosti

Mnoge B2B‑strukovne aplikacije su VCL‑bazirane i koriste dugoročno proizvedene UI‑komponente. To samo po sebi nije problem — ali UI je često mjesto gdje se ovisnosti koncentriraju: PDF‑printeri, generatori barkoda, biblioteke za obradu slika, browser‑kontrole, COM‑objekti. Za ARM64 vrijedi pravilo: što više UI‑specifičnih komponenata koristite, to je važnija rana lista kompatibilnosti.

U multiplatformskim strategijama (npr. Windows + macOS) često se pojavljuje FMX. Neovisno o frameworku, robusna strategija je odvojiti poslovnu logiku i integracije od UI‑a. To doprinosi i Delphi Multiplatform pristupima i podržava Windows 11 ARM64.

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

U praksi se većina ARM64‑problema može prepoznati rano, ako se sistematski inventarizira i provede „ARM64 Readiness“ provjera. Bitno je ne gledati samo Delphi‑kod, nego sve što pripada proizvodu: installer, drajvere, konfiguracije, pluginove, alate trećih strana, update‑lanac, support skripte.

1) Nativne DLL‑ove, BPL‑ove i miješane procesne krajolike

Mnoge Delphi‑aplikacije učitavaju dodatne DLL‑ove: kriptografiju, CAD‑viewer, OCR, potpis, hardverske SDK‑ove, specijalne parsere. Na x64 se često implicitno pretpostavlja da „postoji 64‑bit DLL“. Za ARM64 je drugačije: potrebni su eksplicitni ARM64 binarni fajlovi ili arhitektura koja tu ovisnost uklanja iz klijenta.

Pragmatičan pristup:

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

Čest nalaz: jedan jedini x64‑only modul blokira čitav ARM64‑klijent. Tada se isplati jasno slojevito arhitekturno rješenje: UI/klijent ostaje lagan, integracije se premještaju u kontrolisane server/servis slojeve.

2) COM, Office‑Automation i Shell‑integracije

U mnogim organizacijama Word/Excel eksport, Outlook‑povezivanje, Explorer kontekstni meniji ili DMS‑integracije historijski su rađeni preko COM‑a. COM nije automatski „ARM64‑ready“, naročito ako dobavljači COM‑servera ili add‑inova isporučuju samo x64. Rad sa mješavinom 32‑/64‑bita (Out‑of‑Proc vs. In‑Proc) brzo postaje kompleksan.

Rana rasprava treba obuhvatiti:

• Koji COM‑objekti se koriste (lista ProgID/CLSID)?
• In‑Proc ili Out‑of‑Proc? Postoje li ARM64 registracije?
• Može li se eksport riješiti server‑side bibliotekama (npr. dokument‑bazirani formati) umjesto Office‑automation?

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

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

Pristup podacima je česta ARM64 tačka jer drajverski ekosistemi i klijentske biblioteke igraju veliku ulogu. Kritični su stari ODBC‑setupi, vlasnički klijenti za baze ili lokalne baze sa historijskim slojevima pristupa.

Za Delphi‑stackove ovo je klasik: ako su još prisutni Borland BDE, stare Paradox strukture ili teško održive drajverske lance, ARM64 postaje katalizator. BDE‑Ablösung i prelazak na BDE‑ablösung s nativnim pristupom s jasno definiranim DB‑drajverima značajno smanjuje rizike platforme.

Konkrektni provjerljivi punktovi:

• Koje baze se koriste (SQL Server, PostgreSQL, MariaDB, Firebird, lokalni enginei)?
• Koje drajvere koristite (ODBC, native client, BDE-Ablosung mit nativer Anbindung‑drajver, OLE DB)?
• Gdje su connection‑stringovi i DSN‑ovi pohranjeni (po korisniku, po mašini, u installeru)?
• Postoje li zavisnosti od 32‑bit ODBC‑drajvera ili starih providera?

Čak i za SQL Server/ODBC, ARM64‑klijent može raditi — ali samo ako je drajverski lanac i instalacijska rutina čista. To nije nešto što želite debugirati „na terenu”.

4) Reporting, štampa, skeniranje, PDF i output‑workflowi

Output u strukovnim aplikacijama često je poslovno kritičan: otpremnice, etikete, računi, zapisnici, očitavanja mjerača, certifikati, shipping labeli. Mnogi od tih workflowa ovise o reporting komponentama ili specifičnim drajverima za štampače/skenere.

Na Windows 11 ARM64 tipične zamke su:

• Etiketni/specijalni drajveri dostupni samo kao x64
• Skener softver/SDK bez ARM64 podrške
• Stari report‑enginei sa nativnim preview/export modulima
• Generisanje PDF‑ova preko „virtualnih printera“ umjesto biblioteka

Robustan pristup je standardizovati output‑workflowe: generisati PDF/Office formate preko biblioteka, štampu preko standardiziranih sučelja, a specijalni hardverski pristupi trebaju biti kapsulirani. Gdje to nije moguće, treba rano izraditi matričnu listu uređaja/drajvera za ARM64.

5) Installer, Updater, Code‑Signing i operacija

Mnoge ARM64 inicijative ne propadnu zbog programa, nego zbog načina isporuke: setup pogrešno detektuje arhitekturu, ne instalira drajvere, ne registruje COM, postavlja pogrešne putanje ili zapne na code‑signing pravilima. Automatski updatei (delta‑update, self‑updater) često su također jake arhitekturne tokove.

Ključna pitanja za operaciju:

• Kako se instalira (MSI, Inno Setup, vlastiti updater)?
• Kako se instaliraju zavisnosti (VC++ runtimes, drajveri, certifikati)?
• Kako se potpisuje (EXE, DLL, installer, drajverski paketi)?
• Kako se testira: na pravom ARM64 hardveru ili samo na pretpostavkama?

Za organizacije je to pitanje upravljanja: kad se Windows 11 ARM64 pojavi u klijentskoj floti, deployment mora biti reproducibilan — uključujući rollback, podršku i jasnu verzionost.

Strategija: Windows 11 ARM64 kao „rana nefunkcionalna zahtev“

Ekonomski opravdano je tretirati ARM64 kao nefunkcionalni zahtjev (NFA) — slično kao performanse, sigurnost ili offline‑sposobnost. To znači: ne čekati „dok ne zatreba“, nego uvesti definirana ograničenja za arhitekturu i lanac isporuke.

ARM64‑Readiness‑Check: inventar umjesto osjećaja

Valjana provjera obično obuhvata:

• Inventar zavisnosti: sve third‑party komponente, DLL‑ovi, drajveri, SDK‑ovi, browser‑kontrole, kriptomodule, reporting.
• Analizu build/pipeline: build‑targeti, paketiranje, signiranje, skladištenje artefakata, brojevi verzija, reproducibilnost.
• Installer/update lanac: logika setupa, prerequisiti, Registry/FS putanje, politike, privilegije.
• Operativni model: podrška, logging, crash‑dumpovi, telemetrija (ako postoji), plan rollouta.

Rezultat ne treba biti samo „ARM64: da/ne“, nego prioritetizirana lista: koji blockeri postoje, koji moduli su pogođeni, koje alternative postoje i koja ulaganja su realna.

Decision‑matrix: Nativno na ARM64 ili razdvojiti?

Za svaku problematičnu zavisnost treba donijeti jasnu odluku:

• Moguća ARM64‑native zamjena: nadogradnja, promjena dobavljača, prelazak na drugu biblioteku.
• Zavisnost se može izuzeti: npr. premjestiti u Windows servis, background worker ili centralni REST‑server.
• Zavisnost mora ostati lokalna: npr. ako je hardver direktno vezan za klijent. Tada su potrebna obavezujuća ARM64‑hardverska/drajverska odobrenja.

Za integracije je često najbolje izdvajanje: klijent ostaje UI + dijalozi, dok kompleksna integracijska logika živi u kontrolisanim servisima. To pomaže ne samo ARM64‑ciju, nego i centralne update‑e, model prava i bolju testabilnost.

Arhitekturni paterni koji stabilizuju ARM64‑projekte

Ako se Windows 11 ARM64 planira rano, moguće je donijeti arhitektonske odluke koje se kasnije ne moraju skupo mijenjati.

1) Jasni slojevi: UI, poslovna logika, integracija, pristup podacima

Rastući Delphi‑klijenti često drže „sve u jednom procesu“: UI, poslovna pravila, pristup podacima, DMS‑povezivanje, štampa i eksport. To je održivo dok platforma ostaje ista. Kad se pojave varijante platformi (ARM64, eventualno macOS, eventualno terminal server), vrijednost jasne slojevitosti raste.

Pragmatična ciljna slika:

• UI‑sloj: minimalan, testabilan, bez direktnih drajver/SDK ovisnosti.
• Poslovna logika: koliko je moguće platformno neutralna, jasno modelirana.
• Integracijski sloj: kapsulira COM, formate datoteka, DMS/ERP konektore, uređaj‑SDK‑ove.
• Pristup podacima: konsolidovan (npr. FireDAC), jasne transakcijske granice, bez rasutih SQL fragmenata.

Ovo nije „akademska vježba“, nego realna ušteda: ako samo integracijski sloj ima ARM64‑probleme, ne morate graditi cijeli klijent iznova.

2) Servisi i REST‑serveri kao stabilna osnova

Mnogi B2B sustavi imaju korist od toga da centralne funkcije budu implementirane kao REST‑server ili kao Windows/ Linux‑servisi: provjera prava, dokumentni workflowi, validacija podataka, eksport/import, konekcije prema ERP/DMS/CRM. Kad ove funkcije rade na serveru, složenost na klijentu značajno opada — i time se redukuje površina za ARM64 probleme.

Tipične podjele koje su se pokazale korisnima:

• Klijent: dijalozi, prikaz, offline logika (ako je potrebna), minimalne lokalne integracije.
• REST‑server: poslovne operacije, validacija, multi‑tenant podrška, centralno logovanje.
• Worker/Service: vremenski zadaci, polling interfesa, generisanje reporta, batch‑eksporti.

To se uklapa i u moderne operativne modele: funkcija koja radi server‑side se ažurira jednom — umjesto na svakom ARM64‑klijentu posebno.

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

Ako je ARM64 cilj, build‑pipeline to treba odražavati. Ne kao „uradit ćemo kasnije poseban build“, nego kao standard: svaka release‑kandidat verzija reproducibilno se gradi za x64 (i, ako je planirano, ARM64), uključujući signiranje i paketiranje instalera.

Manje je važno koji su to alati, a važnija je dosljednost:

• Artefakti jasno imenovani (arhitektura u imenu paketa/strukturi foldera).
• Konfiguracijske vrijednosti razdvojene po targetu (putanje, prerequisiti, drajverski paket).
• Smoke‑testovi definirani za svaku arhitekturu (pokretanje, login, DB‑veza, štampa/PDF).

Tako ARM64 nije „Big Bang“, nego kontrolisani dodatni target.

Delphi‑modernizacija: ARM64 kao prilika za ciljano otplaćivanje tehničkog duga

Mnogi koriste novu platformsku potrebu kao poziv za „sve iznova“. To je rizično i često nepotrebno. Ekonomičnije je koristiti Windows 11 ARM64 kao vodilju za postupnu modernizaciju: uklanjati tehnički dug tamo gdje blokira ARM64 ili ugrožava isporučivost.

64‑bit i Unicode: ne ostavljajte stare probleme neriješenima

Ako u kodnoj bazi još postoje 32‑bit pretpostavke ili naslijeđeni ostaci iz ranih verzija Delphi, oni će isplivati pri promjeni platforme. Iako ARM64 sam po sebi ne znači „Unicode“, mnogi projekti koji ozbiljno pristupaju ARM64 koriste priliku da osiguraju ispravan Unicode, uspostave 64‑bit putanje i saniraju memorijske/pointer teme.

Cilj nije perfekcija, nego pouzdan standard: kod koji se može graditi za nove targete bez ponovnog susreta sa istim klasama grešaka.

BDE‑ablösung i konsolidirani pristup podacima kao enabler za ARM64

Gdje još postoje historijske slojeve pristupa (BDE, lokalne Paradox baze, mješoviti pristupi), konsolidacija je poluga s višestrukim efektima: održiviji kod, stabilniji deploymenti, jasnija drajverska strategija. Sa FireDAC se pristup u mnogim scenarijima može standardizirati, uključujući centralnu konfiguraciju, pooling strategije i urednu obradu grešaka.

Važno: BDE‑ablösung nije samo „zamjena komponenti“. Ona utječe na transakcijsku logiku, tipove podataka, sortiranja, semantiku filtriranja i ponekad i na podatkovni model. Zato treba biti planirana — a ne puščena kao hitna mjera kad se ARM64‑klijenti iznenada pojave u polju.

Testiranje i osiguranje kvaliteta: ARM64 je planiran samo ako je mjerljiv

Rano planiranje ARM64 znači i: mora se testirati — ne nužno kompletan test svakog featurea, nego ciljano testiranje kritičnih lanaca. Najvažniji korak je imati stvarno ARM64 test okruženje. Emulacija može pomoći u pojedinim situacijama, ali ne zamjenjuje praksu na pravom hardveru, sa stvarnim drajverima i sigurnosnim politikama.

Minimalni ARM64‑smoke‑test: šta treba rano pokriti

Pragmatičan, ali učinkovit set smoke testova za svaki release‑kandidat uključuje:

• Pokretanje programa, login, osnovne UI funkcije
• DB‑veza (uključujući autentikaciju, certifikate, DNS/Proxy ako je relevantno)
• Jedan kritičan end‑to‑end proces (npr. kreirati nalog, spremiti, štampati/eksportirati)
• Updater/installer: nova instalacija i update preko jedne verzije
• Logging/poruke o greškama: jesu li dijagnostike razumljive i na ARM64?

To rano otkriva tipične ARM64‑blokere: nedostajuće DLL‑ove, pogrešne drajvere, probleme sa setupom, neočekivane zahtjeve za pravima.

Mogućnost dijagnostike: crash‑dumpovi, logovi, transparentnost verzija

Kad ARM64 bude u floti, doći će support slučajevi — zbog novih kombinacija drajvera i slično. Stoga vrijedi standardizirati dijagnostiku: jasne build‑ID, smisleni logovi, reproducibilni instalacijski i update putevi. To nije specifično za ARM64, ali ARM64 brzo i skupo pokazuje nedostatke.

Rollout i operacija: mješovite flote bez kaosa

Većina organizacija će srednjoročno imati mješovite klijentske flote: dio x64, dio ARM64. Ključ je svjesno upravljanje tim stanjem.

Paketiranje: odvojeni installeri, jasna detekcija, nedvosmisleni download putevi

U praksi najbolje funkcionira kad su installer/paketi jednoznačni: x64‑paket je x64, ARM64‑paket je ARM64. „Jedan installer za sve“ može zvučati praktično, ali brzo postane kompleksan (provjere, prerequisiti, drajverske putanje, signiranje, reparacija instalacije). Za kontrolirane enterprise rollout‑e jednoznačnost je često robusniji put.

Update‑strategija: ARM64 nije iznimka

ARM64 ne treba biti posebna putanja u update procesu. Cilj: ista frekvencija izdanja, ista funkcionalna verzija, ali odvojeni artefakti. Ako se ARM64 ažurira samo ručno, pojavit će se divergencije u floti koje rastu troškove podrške.

Integracije dokumentovati

Mnogi ARM64‑problemi ne stvaraju se u vlastitom kodu, nego u integracijama: ERP‑connector, DMS‑klijent, potpisni servis, skener softver, etiketni printer. Održavana lista integracija s verzijama i arhitektonskim napomenama je za B2B sustave ionako korisna — i čini ARM64‑odluke transparentnim.

Šta preduzeće sada konkretno treba uraditi (bez akcionalizma)

Windows 11 ARM64 rano planirati ne znači odmah sve prepraviti. Radi se o tome da na vrijeme postavite prava pitanja i uklonite blocker‑e dok je napor planabilan. Provjereni pristup je:

• 1) Inventar (2–10 dana, ovisno o veličini sistema): zavisnosti, installer, drajveri, pristup podacima, COM, reporting.
• 2) Ciljna slika i put: Šta mora biti nativno na klijentu? Šta ide u servis/REST? Koje komponente se zamjenjuju?
• 3) Dokaz izvodljivosti: funkcionalan ARM64‑build s installerom i jednim end‑to‑end slučajem upotrebe.
• 4) Postepeno učvršćivanje: preostale funkcije, testovi, update lanac, dijagnostika.

Na taj način ne nastaje zaseban „ARM64‑projekt“ koji mjesecima radi izolovano, nego kontrolisano proširenje sposobnosti isporuke.

Zaključak: Windows 11 ARM64 nije hype, nego rani indikator tehničke zrelosti

Windows 11 ARM64 će za mnoge organizacije postati realnost — kroz nabavku hardvera, zahtjeve za mobilnošću ili standardizaciju. Za Delphi‑aplikacije prava je izazov ne samo izvorni kod, nego cjelokupan sistem ovisnosti, instalacijskih i update procesa, integracija i drajvera. Ko ARM64 planira rano, može strukturirano razjasniti ove tačke, umjesto da ih kasnije, pod pritiskom vremena, „zakrpa“.

Na kraju, ARM64 je koristan test: koliko je vaša aplikacija odvojiva, testabilna i isporučiva? Ako to sada razjasnite, dobit ćete ne samo dodatne opcije platforme, nego i stabilniju osnovu za modernizaciju, servise, REST‑arhitekture i dugoročnu održivost.

Kontaktirajte Net-Base Software GmbH, ako želite da Windows 11 ARM64 opteretno procijenimo u vašoj Delphi‑roadmapi i provedemo uz jasan tehnički put.