Načrtujte Windows 11 ARM64 zgodaj za Delphi-aplikacije

Windows 11 ARM64 v vsakdanjem B2B-obratovanju ni več zgolj posebnost za tehnološke navdušence. Nove generacije prenosnikov, daljša življenjska doba baterij, scenariji »Always-on« in naraščajoča želja po lahkih, mobilnih delovnih mestih povzročajo, da podjetja kupujejo ARM64-kliente – včasih namensko, včasih po naključju prek standardnih modelov v pogodbi. Za ekipe z obstoječo individualno programsko opremo je to jasen signal: ARM64 mora biti zgodaj upoštevana v tehničnem načrtovanju, sicer se kasneje spremeni v drago naknadno nadgradnjo.

Pri Delphi-aplikacijah osrednje vprašanje redko glasi „ali Delphi lahko to prevede?“. V praksi ARM64-rollouti skoraj vedno zataknejo na periferiji: na native DLL-jih, tiskalniških/skener komponentah, gonilnikih za baze podatkov, report-enginih, COM-integracijah, setup-rutinah, code-signingu ali v build-pipelines, ki tiho poznajo le x64. Prav zato se izplača obravnavati Windows 11 ARM64 kot zahtevo arhitekture in obratovanja – ne kot zgolj funkcijo platforme.

Ta prispevek pokaže, kateri tehnični pasti se pri Delphi tipično pojavijo, kako sistematično identificirati tveganja in katere pragmatične migracijske poti so se izkazale – od postopnega pripravljanja posameznih modulov do jasne ciljane arhitekture s storitvami in REST-strežniki.

Zakaj je Windows 11 ARM64 zdaj tema arhitekture

V mnogih podjetjih je bil izraz „Windows“ dolgo časa enakovreden x86/x64. To predpostavko nosijo skripte, installerji, third‑party-komponente in včasih celo model podatkov (npr. poti, registrovski ključi, vmesniki gonilnikov). Ko se pojavijo ARM64-klienti, postane vidno, koliko implicitnega znanja je v sistemu. In prav to je ekonomska jedrnica: pozne prilagoditve niso le „nekaj compiler-flagov“, ampak čiščenje predpostavk, ki so se skozi leta utrdile.

V praksi postane ARM64 relevantna zlasti v treh situacijah:

• Klientska programska oprema z dolgo življenjsko dobo: strokovne aplikacije, ki se uporabljajo 8–15 let in se iterativno širijo. Nova klientna platforma v sredini življenjskega cikla je bolj verjetna kot popolna prenova.
• Mešane flote: terenska služba/servis, upravljalski prenosniki, BYOD-scenariji ali hčerinska podjetja, ki nabavljajo drugo strojno opremo.
• Tlak varnosti in skladnosti: sodoben code-signing, utrjevanje, »least privilege«, nadzorovani updaterji – pri tem se namestitveni in posodobitveni procesi tako ali tako spreminjajo. Takrat se ARM64 smiselno vključuje kot stranska zahteva.

Dobra novica: kdor se že ukvarja z Delphi Modernisierung, prehodom na 64 bit, razvezavo dostopa do podatkov ali z oblikovanjem servisno usmerjene ciljane arhitekture, lahko pogosto »povleče« tudi Windows 11 ARM64 – če je to zapisano zgodaj v backlogu in ne šele ob prvem ARM-stroju v podpori.

Delphi na ARM64: kaj je »enostavno«, kaj je »težko«?

Delphi-projekti se močno razlikujejo: od čistih VCL namiznih klientov do večslojnih sistemov z REST-strežniki, Windows storitvami, report-workerji, integracijskimi komponentami in background jobi. Za Windows 11 ARM64 je odločilno, kateri deli resnično morajo teči nativno na klientu in kateri deli so smiselno odloženi v storitve.

Compiler redko predstavlja glavni problem

Če je lastna koda čista (brez inline-assemblerja, brez starih 32-bitnih predpostavk, brez krhkih pointer-castov, brez zastarelih API-klicev), je prevajanje za novo ciljno platformo pogosto izvedljivo. Problemi nastanejo zaradi:

• Third‑party komponent z nativnimi deli (DLL, BPL, C/C++ mostovi)
• Gonilnikov in priključevanja naprav (tiskanje, skeniranje, podpisne tablice, dongli)
• Dostopa do baze podatkov preko ODBC/OLE DB/klientskih knjižnic, ki niso ARM64-kompatibilne
• Reportinga in integracije z Office (COM‑avtomatizacija, stari export-filtri)
• Installerjev/Updaterjev, ki testirajo le x64 ali uporabljajo trdo kodirane poti

Tako je Windows 11 ARM64 predvsem »test ekosistema«: kako dobro je vaš programski paket odvezan od starih platformnih predpostavk?

VCL, FMX in UI‑odvisnosti

Mnoge B2B-strokovne aplikacije temeljijo na VCL in uporabljajo skozi leta zrasle UI-komponente. To samo po sebi ni problem – a UI je pogosto mesto, kjer se odvisnosti kopičijo: PDF-tiskalniki, generatorji črtnih kod, knjižnice za obdelavo slik, browser-controli, COM-objekti. Za ARM64 velja: več specialnih komponent, ki so vezane na UI, bolj pomemben je zgodnji seznam združljivosti.

Pri multiplatformnih strategijah (npr. Windows + macOS) se pogosto pojavi FMX. Ne glede na framework je robustna strategija ločiti poslovno logiko in integracije od UI. To koristi tako Delphi Multiplattform kot tudi Windows 11 ARM64.

Tipične tehnične pasti (in kako jih zgodaj prepoznati)

V praksi je večino ARM64-problemov mogoče odkriti zgodaj, če izvedete strukturirano inventuro in opravite »ARM64 Readiness«‑preverbo. Ključno je, da ne gledate le Delphi-kode, temveč vse, kar sodi k produktu: installerje, gonilnike, konfiguracijo, vtičnike, orodja tretjih, verigo posodobitev, support-skripte.

1) Native DLL, BPL in mešane procesne krajine

Številne Delphi-aplikacije nalagajo dodatne DLL-je: kriptografija, CAD-viewerji, OCR, podpisi, hardware-SDKji, specialni parserji. Na x64 se pogosto implicitno predpostavlja, da »obstaja 64‑bitna DLL«. Pri ARM64 je drugače: potrebni so izrecno ARM64‑binarji ali arhitektura, ki to odvisnost odstrani iz klienta.

Pristop v praksi:

• Naredite seznam vseh naloženih nativnih modulov (tudi posredno preko komponent).
• Klasificirajte: »ARM64 na voljo«, »samo x64«, »samo 32‑bit«, »nejasno«.
• Ocenite, ali modul resnično mora biti lokalno ali ga je mogoče izložiti kot storitev.

Pogost izsledek: en sam x64‑only modul blokira celoten ARM64‑klient. Takrat postane čista slojna oziroma Layer-3 arhitektura ekonomsko smiselna: UI/klient ostane lahkoten, integracije se premaknejo v kontrolirane strežniške/servisne plasti.

2) COM, Office‑avtomatizacija in Shell‑integracije

V mnogih podjetjih so Word/Excel‑export, Outlook‑povezave, kontekstni meniji v Explorerju ali DMS‑integracije zgodovinsko zgrajene preko COM. COM ni avtomatično »ARM64‑ready«, še posebej če ponudniki tretjih dostavljajo le x64 COM‑serverje ali add‑ine. Tudi delovanje 32‑bit/64‑bit mešanic (out‑of‑proc vs. in‑proc) postane hitro kompleksno.

Zgodnja pojasnila:

• Kateri COM‑objekti se uporabljajo (seznam ProgID/CLSID)?
• In‑Proc ali Out‑of‑Proc? Obstajajo ARM64‑registracije?
• Je mogoče izvoz rešiti preko strežniških knjižnic (npr. dokumentno usmerjeni formati) namesto Office‑avtomatizacije?

To je pogosto vzvod modernizacije: premik od UI‑vezane avtomatizacije k reproducibilnim export‑storitevam (npr. PDF/Excel preko knjižnice), ki so uporabne tako za Windows x64 kot za ARM64 ali celo Linux‑strežnike.

3) Dostop do baze podatkov: ODBC, klientske knjižnice, legacy‑BDE

Dostop do podatkov je pogosta ARM64‑vstopna točka, ker tukaj igrajo vlogo gonilniške krajine in klientske knjižnice. Še posebej kritični so stari ODBC‑setupi, lastniški DB‑klienti ali lokalne baze z zgodovinskimi plasti dostopa.

Za Delphi‑stacke je to klasika: če so še Borland BDE, stare Paradox‑strukture ali težko vzdržljive verige gonilnikov v igri, ARM64 deluje kot katalizator. BDE‑zamenjava in prehod na BDE‑Ablösung mit nativer Anbindung z jasno DB‑gonilniško strategijo znatno zmanjšata platformna tveganja.

Konkrektni kontrolni točki:

• Kateri DB‑ji se uporabljajo (SQL Server, PostgreSQL, MariaDB, Firebird, lokalni enginei)?
• Kateri gonilniki se uporabljajo (ODBC, nativni klient, BDE-Ablosung mit nativer Anbindung‑gonilnik, OLE DB)?
• Kje so connection‑stringi in DSN‑i shranjeni (na uporabnika, na stroj, v installer)?
• Ali obstajajo odvisnosti od 32‑bit ODBC‑gonilnikov ali starih providerjev?

Pri SQL Server/ODBC lahko ARM64‑klient deluje – vendar le, če je gonilniška veriga in namestitvena rutina urejena. To ni stvar, ki jo želite »na terenu« debugirati.

4) Reporting, tiskanje, skeniranje, PDF in output‑workflovi

Output je v strokovnih aplikacijah pogosto poslovno kritičen: dobavnice, etikete, računi, protokoli, odčitki merilnikov, potrdila, pošiljalne nalepke. Veliko teh potekov je vezanih na reporting‑komponente ali specifične gonilnike za tiskalnike/skenerje.

Na Windows 11 ARM64 so pasti tipično:

• Etiketni/specialni gonilniki na voljo le v x64
• Skener‑programska oprema/SDK‑ji brez ARM64‑podpore
• Stari report‑engini z nativnimi preview/eksport moduli
• Ustvarjanje PDF preko »virtualnih tiskalnikov« namesto knjižnice

Robusten pristop je standardizirati output‑workflove: PDF/Office‑formate ustvarjati preko knjižnic, tiskanje preko standardiziranih vmesnikov, posebne strojne dostopne funkcije povsod enkapsulirati. Kjer to ni mogoče, potrebuje zgodnja ARM64‑matrika naprav/gonilnikov.

5) Installer, Updater, Code‑Signing in obratovanje

Veliko ARM64‑projektov ne spodleti zaradi programa samega, temveč zaradi načina dostave: setup narobe zazna arhitekturo, ne namesti gonilnikov, ne registrira COM, nastavi napačne poti ali zapre na code‑signing pravilnikih. Tudi avtomatske posodobitve (delta‑updates, self‑updaterji) so pogosto močno vezane na arhitekturo.

Pomembna vprašanja za obratovanje:

• Kako se namešča (MSI, Inno Setup, lasten updater)?
• Kako se nameščajo odvisnosti (VC++ Runtimes, gonilniki, certifikati)?
• Kako se podpise: EXE, DLL, installer, gonilniški paketi?
• Kako se testira: prava ARM64‑strojna oprema ali le domneve?

Za podjetja je to vprašanje governance: ko se Windows 11 ARM64 pojavi v klientni floti, mora biti deployment reproducibilen – vključno z rollbackom, podporno sposobnostjo in jasnim verzioniranjem.

Strategija: Windows 11 ARM64 kot »zgodnja nefunkcionalna zahteva«

Ekonomsko smotrna metoda je obravnavati ARM64 kot nefunkcionalno zahtevo (NFA) – podobno kot performanca, varnost ali offline‑zmožnost. To pomeni: ne šele v sprintu »ko zagori«, ampak kot definirano vodilo za arhitekturo in dobavno verigo.

ARM64‑Readiness‑Check: inventar namesto občutka

Robusten check običajno vključuje:

• Inventar odvisnosti: vse third‑party komponente, DLL, gonilniki, SDKji, browser‑controlli, kriptomoduli, reporting.
• Analizo build/pipeline: build‑targeti, paketiranje, podpisovanje, shranjevanje artefaktov, številčenje verzij, reproducibilnost.
• Verigo installerja/posodobitev: logika setupa, prerequisites, registry/datotečne poti, politike, pravice.
• Model obratovanja: podpora, logging, crash‑dumps, telemetrija (če obstaja), rollout‑načrt.

Rezultat ne bi smel biti zgolj »ARM64: da/ne«, temveč prioritetni seznam: kateri blokatorji obstajajo, kateri moduli so prizadeti, katere alternative so na voljo in kakšna investicija je realna.

Odločitvena matrika: nativno na ARM64 ali razvezati?

Pri vsaki problematični odvisnosti pride v poštev jasna odločitev:

• ARM64‑nativna zamenjava možna: nadgradnja, zamenjava proizvajalca, prehod na drugo knjižnico.
• Odvisnost je mogoče izložiti: npr. v Windows storitev, background worker ali centralni REST‑strežnik.
• Odvisnost mora ostati lokalna: npr. ker je strojna oprema neposredno priključena na klient. Takrat so potrebne obvezne ARM64‑strojne/gonilniške odobritve.

Za integracije je izložitev pogosto najčistejša pot: klient ostane UI + poslovni dialogi, kompleksna integracijska logika pa teče v kontroliranih storitvah. To poleg ARM64 podpira tudi centralne posodobitve, model pravic in boljšo testabilnost.

Arhitekturni patterni, ki naredijo ARM64‑projete stabilne

Če je Windows 11 ARM64 načrtovana zgodaj, je mogoče sprejeti več arhitekturnih odločitev tako, da kasneje ne bodo drage za vračanje.

1) Jasne plasti: UI, poslovna logika, integracija, dostop do podatkov

Rastoči Delphi-klienti pogosto vsebujejo »vse v enem procesu«: UI, poslovna pravila, dostop do podatkov, DMS‑povezave, tisk in export. To je vzdržno, dokler platforma ostaja enotna. Ko pa postanejo relevantne platformne variante (ARM64, mogoče macOS, mogoče terminalni strežniki), vrednost jasne plasti hitro naraste.

Pragmatični cilj:

• UI‑plast: minimalna, testabilna, brez neposrednih gonilniških/SDK odvisnosti.
• Poslovna logika: čim bolj plattformno neodvisna, jasno modelirana.
• Integracijska plast: enkapsulira COM, datotečne formate, DMS/ERP‑connectorje, device‑SDKje.
• Dostop do podatkov: konsolidiran (npr. FireDAC), jasne transakcijske meje, brez raztresenih SQL‑fragmentov.

To ni akademija, ampak prihrani resnične stroške: če je problem samo v integracijski plasti, ni treba precepiti celotnega klienta.

2) Storitve in REST‑strežniki kot steber stabilnosti

Mnogi B2B‑sistemi imajo koristi od izvajanja centralnih funkcij kot REST‑strežniki ali kot Windows/ Linux‑storitev: preverjanje pravic, dokumentni workflowi, validacija podatkov, export, import, vmesniki do ERP/DMS/CRM. Ko te funkcije tečejo strežniško, se kompleksnost na klientu znatno zmanjša – s tem tudi ARM64‑površina napada.

Tipične delitve, ki so se izkazale:

• Klient: dialogi, prikaz, offline logika (če je potrebna), minimalne lokalne integracije.
• REST‑strežnik: strokovne operacije, validacija, večnajemniški režim, centralno beleženje.
• Worker/Service: časovno sproženi jobi, polling vmesnikov, generiranje poročil, batch‑eksporti.

To se sklada tudi z modernimi operativnimi modeli: funkcija, ki teče strežniško, se posodobi enkrat – ne na vsakem ARM64‑klientu posebej.

3) Build‑sistem, več targetov (x64 + ARM64) od začetka

Če je ARM64 cilj, naj to odseva tudi build‑pipeline. Ne kot »kasneje naredimo poseben build«, temveč kot standard: vsak release‑kandidat se reproducibilno zgradi za x64 (in, če je predvideno, za ARM64), vključno s podpisovanjem in paketiranjem installerja.

Pomembnejše od orodij je doslednost:

• Artefakte jasno poimenujte (arhitektura v imenu paketa/mape).
• Konfiguracijske vrednosti po targetih ločite (poti, prerequisites, gonilniški paketi).
• Opredelite smoke‑teste po arhitekturi (zagon, login, DB‑povezava, tisk/PDF).

Tako ARM64 ne postane »Big Bang«, ampak nadzorovan dodaten target.

Delphi‑modernizacija: ARM64 kot priložnost za ciljano odpravo tehničnega dolga

Mnoga podjetja izkoriščajo nove platformne zahteve kot povod za »vse na novo«. To je tvegano in pogosto nepotrebno. Bistveno bolj ekonomično je uporabiti Windows 11 ARM64 kot vodilo za postopno modernizacijo: odpravljati tehnični dolg tam, kjer blokira ARM64 ali ogroža dobavnost.

64‑bit in Unicode: ne puščajte starih gradbenih defektov

Če v kodi še vedno kraljujejo 32‑bitne predpostavke ali bremena iz zgodnjih različic Delphi, se to ob prehodu platforme ponovno pojavi. Čeprav ARM64 ni samodejno enako Unicode, številni projekti, ki resno pristopijo k ARM64, istočasno uredijo Unicode, uveljavijo 64‑bit poti in razčistijo spominske/pointer tematike.

Cilj ni popolnost, ampak zanesljiv standard: koda, ki jo je mogoče graditi za nove targete brez ponavljanja istih razredov napak.

BDE‑zamenjava in konsolidiran dostop do podatkov kot ARM64‑omogočevalec

Kjer še obstajajo zgodovinske plasti dostopa ( [[NBML_TERM_11_901e2bf2 ]], lokalni Paradox podatki, mešani dostopi), je konsolidacija vzvod z večkratnim učinkom: vzdrževalnejša koda, stabilnejši deploymenti, jasnejša gonilniška strategija. S FireDAC se dostop v mnogih scenarijih lahko poenoti, vključno s centralnim upravljanjem parametrov, pooling strategijami in čisto obravnavo napak.

POMEMBNO: BDE‑zamenjava ni le »zamenjaj komponento«. Vpliva na transakcijsko logiko, tipe podatkov, sortiranja, filtrirno semantiko in deloma tudi podatkovni model. Zato naj bo to načrtovano, ne ukrep v sili, ko se ARM64‑klienti nenadoma pojavijo v produkciji.

Testiranje in zagotavljanje kakovosti: ARM64 je načrtljiv le, če je merljiv

Zgodnje načrtovanje ARM64 pomeni tudi: potrebno ga je testirati – ne kot popoln pregled vsake funkcije, ampak kot ciljno testiranje tveganih verig. Najpomembnejši korak je imeti resnično ARM64 testno okolje. Emulacija lahko posamezno pomaga, a ne nadomesti izkušenj z dejansko strojno opremo, pravimi gonilniki in dejanskimi varnostnimi politikami.

Minimalni ARM64‑smoke‑test: kaj mora biti zgodaj pokrito

Pragmatičen, a učinkovit smoke‑test set za vsak release‑kandidat:

• Zagon programa, login, osnovne UI‑funkcije
• DB‑povezava (vključno z avtentikacijo, certifikati, DNS/proxy, če je relevantno)
• En ključen proces »end‑to‑end« (npr. ustvarjanje naloga, shranjevanje, tisk/eksport)
• Updater/Installer: nova namestitev in posodobitev čez verzijo
• Logging/diagnoze: so diagnostični podatki tudi na ARM64 uporabni?

S tem postanejo tipični ARM64‑blokatorji zgodaj vidni: manjkajoče DLL, napačni gonilniki, setup‑težave, nepričakovane zahteve po pravicah.

Diagnostična sposobnost: crash‑dumps, logi, preglednost verzij

Ko je ARM64 v floti, bodo primeri podpore prišli – že zaradi novih kombinacij gonilnikov. Zato se izplača standardizirati diagnostiko: jasne build‑ID, povedni logi, reproducibilne namestitvene in posodobitvene poti. Ni to specifično za ARM64, vendar ARM64 pomanjkljivosti tu hitro podraži.

Rollout in obratovanje: mešane flote brez kaosa

Večina podjetij bo srednjeročno upravljala mešane klientne flote: del x64, del ARM64. Ključ je v zavestni ureditvi tega stanja.

Paketiranje: ločeni installerji, jasna detekcija, nedvoumne poti prenosa

V praksi najbolje deluje, če so installerji/paketi nedvoumni: x64‑paket je x64, ARM64‑paket je ARM64. »Eden installer za vse« se morda zdi priročen, a hitro postane kompleksen (logika preverjanja, prerequisites, gonilniške poti, podpisovanje, popravki namestitve). Za nadzorovane enterprise rolloute je nedvoumnost pogosto robustnejša pot.

Strategija posodobitev: brez posebnih poti za ARM64

ARM64 naj ne bo poseben primer v procesu posodabljanja. Cilj: enaka frekvenca izdaje, ista številka funkcijske verzije, a ločeni artefakti. Če se ARM64 posodablja le »ročno«, nastajajo odstopanja v floti, ki kasneje povečajo stroške podpore.

Integracije skrbno dokumentirajte

Veliko ARM64‑težav ni v lastni kodi, temveč v integracijah: ERP‑connector, DMS‑klient, servis podpisov, skener‑programska oprema, etiketni tiskalnik. Vzdrževan seznam integracij z verzijami in arhitekturnimi opombami je za B2B‑sisteme smiselna praksa – in poenostavi ARM64‑odločitve.

Kaj naj podjetja zdaj naredijo (brez akcionarstva)

Zgodnje načrtovanje Windows 11 ARM64 ne pomeni takojšnje popolne prenove. Pomeni zgodaj odgovoriti na prava vprašanja in odpraviti blokatorje, dokler je napor planiran. Preizkušen potek:

• 1) Inventura (2–10 dni, odvisno od velikosti sistema): odvisnosti, installerji, gonilniki, dostop do podatkov, COM, reporting.
• 2) Ciljna slika in pot: kaj mora teči nativno na klientu? Kaj bo storitev/REST? Katere komponente se zamenjajo?
• 3) Proof of Feasibility: delujoč ARM64‑build z installerjem in end‑to‑end uporabnim primerom.
• 4) Postopna utrditev: preostale funkcije, testi, veriga posodobitev, diagnostična sposobnost.

Tako ne nastane izoliran »ARM64‑projekt«, ki teče mesece, temveč nadzorovana razširitev dobavne sposobnosti.

Zaključek: Windows 11 ARM64 ni hobi, ampak zgodnji indikator tehnične zrelosti

Windows 11 ARM64 bo za številna podjetja preprosto realnost – zaradi nabave strojne opreme, mobilnostnih zahtev ali standardizacije. Pri Delphi‑aplikacijah izziv ni le izvorna koda, temveč celoten sistem odvisnosti, namestitvenih in posodobitvenih procesov, integracij in gonilnikov. Kdor ARM64 načrtuje zgodaj, te točke lahko strukturirano razčleni, namesto da jih kasneje pod časovnim pritiskom le »zakrpa«.

Na koncu je ARM64 uporaben preskus: kako dobro je vaša aplikacija odvezana, testabilna in dobavljiva? Če to vprašanje odgovorite zdaj, pridobite ne le več platformnih možnosti, temveč tudi stabilnejšo osnovo za modernizacijo, storitve, REST‑arhitekture in dolgoročno vzdrževanje.

Kontaktirajte Net-Base Software GmbH, če želite Windows 11 ARM64 v vaši Delphi‑roadmapi zanesljivo oceniti in izvesti s jasnim tehničnim načrtom.