Gera ráð fyrir Windows 11 ARM64 snemma fyrir Delphi-forrit

Windows 11 ARM64 er í daglegu B2B-umhverfi ekki lengur aðeins sértilvik fyrir tækniaðdáendur. Nýjar fartölvuöld, lengri rafhlöðuending, „Always-on“-sviðmyndir og aukinn þrýstingur fyrir léttum, hreyfanlegum vinnustöðum valda því að fyrirtæki kaupa ARM64-klienta – stundum meðvitað, stundum óvart í gegnum samninga um staðalgerðir. Fyrir teymin með vaxandi sérhannaðan hugbúnað er þetta skýr skilaboð: ARM64 þarf að koma snemma inn í tæknilega áætlun, annars verður það síðar dýr eftirfærslutilraun.

Hjá Delphi-forritum er lykilspurningin sjaldan „getur Delphi þýtt þetta?“. Í raun og veru bregðast ARM64-innleiðingar nánast alltaf á jaðrinum: við innfæddar DLLs, prent-/skönnunarhluta, gagnagrunnsrekla, report-engines, COM-aðlögun, uppsetningarútbúnað, Code-Signing eða build-pipelines sem í reynd þekkja aðeins x64. Einmitt þess vegna borgar sig að meðhöndla Windows 11 ARM64 sem arkitektúr- og rekstrarkröfu – ekki sem hreint platformueiginleika.

Þessi grein sýnir hvaða tæknilegu steinarnir liggja venjulega fyrir Delphi-kerfi, hvernig hægt er að greina áhættuna kerfisbundið og hvaða hagnýtu færsluleiðir hafa reynst árangursríkar – frá stigvaxandi aðlögun einstakra módula að skýru markarkitektúr með þjónustum og REST-serverum.

Af hverju er Windows 11 ARM64 nú arkitektúrmál

Í mörgum fyrirtækjum hefur „Windows“ lengi verið samnefnari fyrir x86/x64. Sú forsendu liggur í skriftum, installurum, þriðja aðila íhlutum og stundum jafnvel gagnalíkani (t.d. slóðir, Registry-lyklar, driver-viðmót). Þegar ARM64-klientar birtast verður sýnilegt hversu mikið óyrt vitneskja er bundin inn í kerfið. Og þetta er kjarni hagfræðinnar: seinar aðlögur eru ekki aðeins „nokkrir compiler-flags“, heldur hreinsun á forsendum sem hafa herðst yfir mörg ár.

ARM64 verður hagnýtt sérstaklega í þremur aðstæðum:

• Klienthugbúnaður með langa líftíma: Sérfræðiforrit sem eru notuð í 8–15 ár og þróast stigvaxandi. Ný client-plattform mitt í líftíma er líklegri en full endurbygging.
• Blandaðar stýringar: Söluteymi/viðhald, stjórnunarfartölvur, BYOD-viðhorf eða dótturfyrirtæki sem kaupa ólíka vélbúnað.
• Öryggi og samræmi: Nútíma Code-Signing, harðning, „least privilege“, stjórnaðir uppfærsluflokkar – þá eru uppsetningar- og uppfærsluferlar þannig þegar til skoðunar. Þá er hentugt að samþætta ARM64 sem hliðarkröfu.

Góðu fréttirnar: Sá sem vinnur þegar að Delphi Modernisierung, 64-bita yfirfærslu, aðskilnaði gagnaaðganga eða þjónustuorientaðri markarkitektúr, getur oft „tekið með sér“ Windows 11 ARM64 – að því gefnu að það sé snemma í backlognum og ekki fyrst þegar fyrsta ARM-vélin lendir í supporti.

Delphi á ARM64: Hvað er „einfalt“, hvað er „vandamál“?

Delphi-verkefni eru mismunandi: frá hreinum VCL-skrifborðsklientum að fjöllags-kerfum með REST-server, Windows þjónustum, report-workerum, samþættingarþáttum og bakgrunnsverkefnum. Fyrir Windows 11 ARM64 skiptir mestu hvaða hlutar þurfa í raun að keyra innfæddir á klientinum og hvaða hlutir má með sanngirni færa út í þjónustur.

Sjálfur compilerinn er sjaldan aðalvandi

Ef eiginn kóði er hreinn (engin inline-assembler, engar gamlar 32-bita-forsendur, engir brothættir pointer-cast-ar, engin úrelt API-notkun) er þýðing fyrir nýja target-inn oft framkvæmanleg. Vandamálin koma vegna:

• Third-Party-íhluta með innfæddum hlutum (DLLs, BPLs, C/C++-brýr)
• Drivera og tækatengingar (prentun, skönnun, undirskriftapöddur, donglar)
• Gagnagrunnsaðgangur í gegnum ODBC/OLE DB/Client-Libraries sem eru ekki ARM64-færar
• Reporting og Office-samþætting (COM-Automation, gamlir export-filterar)
• Installer/Updater sem aðeins prófa x64 eða nota harða slóðaskipan

Þetta gerir Windows 11 ARM64 fyrst og fremst að „vistkerfisprófi“: Hversu vel er hugbúðarpakkin þinn aðskilinn frá gömlum platforma-forsendum?

VCL, FMX og UI-háðleikar

Fjölmörg B2B-fagforrit byggja á VCL og nota UI-íhluti sem hafa vaxið á árum. Það er ekki sjálfkrafa vandamál – en UI er oft staðurinn þar sem áhirf safnast: PDF-prentarar, strikamerkjavinnsla, myndabókasöfn, browser-controls, COM-objekt. Fyrir ARM64 gildir: því fleiri sérhæfðir UI-íhlutar sem notaðir eru, því mikilvægari verður snemma samhæfnislisti.

Í fjölplattformu-stefnu (t.d. Windows + macOS) kemur FMX oft til greina. Óháð framework-i er stöðug stefna að að aðskilja faglogík og samþættingar frá UI. Það greiðir bæði fyrir Delphi Multiplattform og fyrir Windows 11 ARM64.

Typísk tæknileg steinagöl (og hvernig greina má þau snemma)

Í framkvæmd er hægt að greina flest ARM64-vandamál snemma ef farið er kerfisbundið í innleiðingu og framkvæma „ARM64 Readiness“-skoðun. Mikilvægast er að ekki sé aðeins skoðaður Delphi-kóðinn, heldur allt sem tilheyrir vöru: installer, driverar, stillingar, plugin, þriðju-tólar, uppfærslukeðja, support-skriptur.

1) Innfæddar DLLs, BPLs og blandaðar ferla-landslög

Margir Delphi-forrit hlaða viðbótar-DLLum: dulkóðun, CAD-útsýn, OCR, undirskrift, hardware-SDKs, sérparserar. Á x64 er oft sjálfgefið að „sé til 64-bita DLL“. Fyrir ARM64 er það hins vegar öðruvísi: þarf sérstaklega ARM64-binary eða arkitektúr sem hreinsar þessa háðar ut úr klientnum.

Praktísk nálgun:

• Setjið upp lista yfir öll innlifuð native-modúl (jafnvel þau sem koma óbeint gegnum íhluti).
• Flokkist: „ARM64 tiltækt“, „x64-only“, „32-bit-only“, „óljóst“.
• Metið hvort mótullinn þurfi endilega að vera staðbundinn eða megi færa í þjónustu.

Algengt niðurstaða: einn einangraður x64-only-mótablokkar getur hindrað allan ARM64-klientinn. Þá kemur skýr lagaskipting eða Layer-3 Architektur sér vel: UI/klientur helst léttur, samþættingar færast í stjórnaðar server-/service-lög.

2) COM, Office-Automation og Shell-samþættingar

Í mörgum fyrirtækjum hafa Word/Excel-export, Outlook-tenging, Explorer-hnappaval eða DMS-samþættingar vaxið upp með COM. COM er ekki sjálfkrafa „ARM64-ready“, sérstaklega ef þriðja aðila COM-servrar eða add-ins eru aðeins í x64-útgáfu. Rekstur blandaðs 32-/64-bita umhverfis (Out-of-Proc vs. In-Proc) verður fljótt flókinn.

Snemma skýring:

• Hvaða COM-objekt eru notuð (ProgIDs/CLSID-listi)?
• In-Proc eða Out-of-Proc? Eru ARM64-skráningar til staðar?
• Má leysa export með server-side bókasöfnum (t.d. skjalamiðuð format) í stað Office-Automation?

Oft er þetta hlekkur í moderniseringu: frá UI-tengdum automation að endanlegum export-þjónustum (t.d. PDF/Excel í gegnum bókasafn) sem virka fyrir bæði Windows x64 og ARM64 eða jafnvel Linux-servera.

3) Gagnagrunnsaðgangur: ODBC, Client-Libraries, Legacy-BDE

Gagnagrunnsaðgangur er algeng ARM64-skipting því drivera- og client-library-landslag spilar þar stórt hlutverk. Sérstaklega viðkvæm eru gömul ODBC-kerfi, einkaréttar gagnagrunnsclientar eða staðbundnir gagnagrunnar með sögulegum aðgangslögum.

Fyrir Delphi-stack er þetta klassískt: ef Borland BDE, gamlar Paradox-uppbyggingar eða illa viðhaldnar driver-keðjur eru í notkun, þá verður ARM64 hvati til breytinga. Sterk BDE-Ablösung og skipti yfir í BDE-Ablösung mit nativer Anbindung með skýrri DB-driver-stefnu lækkar platformaáhættu verulega.

Ákveðnir prófpunktar:

• Hvaða gagnagrunnar eru í notkun (SQL Server, PostgreSQL, MariaDB, Firebird, staðbundnar vélar)?
• Hvaða driverar eru notaðir (ODBC, native client, BDE-Ablosung mit nativer Anbindung-driverar, OLE DB)?
• Hvar eru connection-strings og DSN-skrár staðsettar (fyrir notanda, fyrir vél, í installer)?
• Er til háð við 32-bita ODBC-driver eða gamlar provider-aðgerðir?

Jú, við SQL Server/ODBC getur ARM64-klient virkað – en aðeins ef driver-keðjan og uppsetningarferlið eru hreinsuð. Þetta er ekki mál sem mann vill „debugga á staðnum“.

4) Reporting, prentun, skönnun, PDF og útflutningsferlar

Úttak er í fagforritum oft viðskiptafræðilegt: föluskrár, merkimiðar, reikningar, skýrslur, mæliskrár, vottorð, sendingamerki. Fjölmargir þessara ferla byggja á report-íhlutum eða sérstökum prentara-/skanna-driverum.

Á Windows 11 ARM64 eru algengar álíkanir:

• Merkimiða-/sérprentaradrífar aðeins í x64-útgáfu
• Skannarhugbúnaður/SDK án ARM64-stuðnings
• Gamlar report-engines með innfæddum preview-/export-módulum
• PDF-myndun í gegnum „virtual printers“ í stað bókasafns

Traust leið er að stöðla úttaksferla: búa til PDF/Office-format í gegnum bókasöfn, senda prentbeiðnir í gegnum staðlaðar grænur, og hylja sérstakan vélbúnað. Þar sem það er ekki hægt þarf snemma tæknimat á vélbúnaði/driverum fyrir ARM64.

5) Installer, Updater, Code-Signing og rekstur

Mörg ARM64-verkefni ganga ekki út á forritið sjálft heldur á afhendinguna: Setup greinir ræktað arkitektúr rangt, setur ekki upp drivera, skráir ekki COM, notar ranga slóð eða festist á Code-Signing-reglum. Einnig eru sjálfvirkar uppfærslur (delta-updates, self-updaters) oft mjög arkitektúrháðar.

Mikilvæg spurningar fyrir rekstur:

• Hvernig er uppsett (MSI, Inno Setup, eigin updater)?
• Hvernig eru háðir settir upp (VC++ runtimes, driverar, vottorð)?
• Hvernig er skráð (EXE, DLL, installer, driver-pakkar)?
• Hvernig er prófað: raunveruleg ARM64-harðvara eða aðeins forsendur?

Fyrir fyrirtæki er þetta stjórnunarmál: Þegar Windows 11 ARM64 birtist í klient-flota þarf deployment að vera endurleikjanlegt – með rollback, support- getu og skýrri útgáfu-stjórnun.

Stefna: Windows 11 ARM64 sem „snemma ekki-fallandi krafa“

Hagkvæmustu nálgunin er að meðhöndla ARM64 sem ekki-fallandi kröfu (NFA) – líkt og frammistöðu, öryggi eða offline-hæfni. Það þýðir: ekki fyrst í sprintinu „þegar eldur kviknar“, heldur sem skilgreind leiðarljós fyrir arkitektúr og afhendingarkeðju.

ARM64-Readiness-Check: Birgðaskrá í stað tilfinningar

Traust skoðun inniheldur yfirleitt:

• Háða-inventar: allir third-party-íhlutar, DLLs, driverar, SDKs, browser-controls, dulkóðunarmodúl, reporting.
• Build-/pipeline-greining: build-targets, pökkun, skráning, artifact-geymsla, útgáfunúmer, endurleikinleiki.
• Installer-/update-keðja: setup-rökfræði, forkröfur, Registry/slóðir, pólitíkur, réttindi.
• Rekstrarlíkan: support, logging, crash-dumps, telemetría (ef til staðar), rollout-plan.

Niðurstaðan ætti ekki að vera „ARM64: já/nei“ heldur forgangsraðað listalýsingu: hvaða blokkar eru til staðar, hvaða módular eru áhyggjuefni, hvaða valkostir eru til og hver fjárfesting er raunsæ.

Ákvörðunar-matrix: Innfæddur ARM64 eða afmörkun?

Fyrir hvern vandamálaháðan hluta þarf skýra ákvörðun:

• ARM64-innfæddur staðgengill mögulegur: uppfærsla, skipt yfir, önnur bókasafn.
• Háð má færa út: t.d. í Windows þjónustu, bakgrunns-worker eða miðlægan REST-server.
• Háð þarf að vera staðbundið: t.d. vegna þess að vélbúnaður er beint tengdur clientinum. Þá þarf skýrar ARM64-harðvara-/driver-leyfi.

Fyrir samþættingar er útsetning oft hagstæðasta leiðin: klienturinn heldur UI + fagdialogum, en flókin samþættingarhluti fer í stjórnaðar þjónustur. Þetta styður bæði ARM64 og atriði eins og miðlægar uppfærslur, aðgangsstýringar og betri prófanleika.

Arkitektúr-mynstur sem stöðva ARM64-verkefni

Ef Windows 11 ARM64 er tekið snemma með í reikninginn er hægt að taka arkitektúrákvarðanir sem síðar þarf ekki að kosta mikið að leiðrétta.

1) Skýr lögun: UI, faglogík, samþætting, gagnaaðgangur

Vaxandi Delphi-klientar hafa oft „allt í einu ferli“: UI, viðskiptareglur, gagnaaðgang, DMS-tenging, prent og export. Þetta er viðhaldanlegt meðan platforminn helst eins. Þegar platformabreytingar (ARM64, mögulega macOS, mögulega terminalserver) verða mikilvægar eykst verðmæti skýrrar lagskiptingar.

Pragmatísk markmynd:

• UI-lag: minimal, prófanlegt, engar beinar driver-/SDK-háðleikar.
• Faglogík: eins platforma-hlutlaus og hægt er, vel modellerað.
• Samþættingarlag: hylur COM, skjalasnið, DMS/ERP-connectora, tæka-SDKs.
• Gagnaaðgangur: samræmdur (t.d. FireDAC), skýrar viðskiptamörk, engar dreifðar SQL-vegakantar.

Þetta er ekki „akademiskt“ heldur sparar raunverulega kostnað: ef aðeins samþættingarlagið er ARM64-vandamál þarf ekki að endurreisa allan klientinn.

2) Þjónustur og REST-serverar sem stöðugleikastaurar

Mörg B2B-kerfi hagnast á því að reyna miðlægar aðgerðir sem REST-server eða sem Windows-/ Linux-services: aðgangsstýring, skjalaflæði, gagnastýring, export, import, tengingar við ERP/DMS/CRM. Þegar þessar aðgerðir keyra á server-hliðinni minnkar flækjustigið á clientinum verulega – og þar með ARM64-árásarsvæðið.

Algengar uppstillingar sem hafa reynst vel:

• Klient: dialogar, birting, offline-logík (ef þarf), lágmarksstaðbundnar samþættingar.
• REST-Server: faglegar aðgerðir, staðfesting, margföldun, miðlæg logging.
• Worker/Service: tímaáætlaðar jobbar, polling í tengingar, report-framleiðsla, batch-exportar.

Þetta fellur vel að nútíma rekstrarlíkönum: aðgerð sem keyrir á server er uppfærð einu sinni í stað þess að þurfa að uppfæra hvern ARM64-klient sérstaklega.

3) Ein byggingarkerfi, mörg target (x64 + ARM64) frá upphafi

Ef ARM64 er markmið ætti build-pipeline að endurspeglast það. Ekki sem „gerum seinna sér-build“, heldur sem staðall: Hver útgáfu-umferð byggist endurleikjanlega fyrir x64 (og ef fyrirhugað, ARM64), þ.m.t. skráningu og pakkun.

Mikilvægari en tólaval er fylgni:

• Nefnið artifacts skýrt (arkitektúr í pakkanöfnum/möppuskipan).
• Aðgreinið stillingar eftir target (slóðir, forkröfur, driver-pakkar).
• Skilgreinið smoke-próf eftir arkitektúr (start, login, DB-tenging, prent/PDF).

Þannig verður ARM64 ekki „Big Bang“ heldur stýrður aukamarkmiði.

Delphi-modernisering: ARM64 sem tækifæri til að greiða úr tæknilegum skuldum

Fjölmörg fyrirtæki nota nýjar plattformakröfur sem afsökun til „allt upp á nýtt“. Það er áhættusamt og oft óþarfi. Miklu hagkvæmara er að nota Windows 11 ARM64 sem leiðarljós fyrir stigvaxandi moderniseringu: greiða úr tæknilegum skuldum þar sem þær hindra ARM64 eða ógna afhendingargetu.

64-bita og Unicode: látið ekki gömul vandamál sitja eftir

Ef kóðabasi inniheldur enn 32-bita-forsendur eða sögulegar byrðar úr eldri Delphi-útgáfum koma þau upp við platformaskipti. Þó ARM64 þýði ekki sjálfkrafa Unicode, þá nýta mörg verkefni ARM64-aðganginn til að tryggja að Unicode sé rétt meðhöndlað, 64-bita slóðar séu stöðvaðar og minnis-/pointer-vandamál séu leyst.

Markmiðið er ekki fullkomnun heldur áreiðanlegur staðall: kóði sem byggist fyrir ný markmið án endurtekinna sömu villutegunda.

BDE-Ablösung og samræmdur gagnaaðgangur sem ARM64-hvetjari

Þar sem enn eru sögulegar aðgangslög (BDE, staðbundin Paradox-gögn, blandaðir gagnaaðgangar) er samræming öflugur hlekkur: viðhaldanlegri kóði, stöðugri deployment, skýrari driver-stefna. Með FireDAC má samræma aðgang í mörgum tilvikum, þ.m.t. miðlæga stillingastjórnun, pool-strategíu og hreina villumeðhöndlun.

Mikilvægt: BDE-Ablösung er ekki aðeins „skipti á componentum“. Hún snertir viðskiptatransaction, gagnategundir, röðun, filter-semantík og stundum gagnalíkan. Þess vegna ætti hún að vera vel skipulögð – ekki neyðarúrræði þegar ARM64-klientar birtast í reitnum.

Prófanir og gæðastýring: ARM64 er bara áætlun ef hægt er að mæla

Að plana ARM64 snemma þýðir einnig: það þarf að prófa – ekki fulla prófun á hverri aðgerð heldur áhættuprófanir á mikilvægustu keðjunni. Mikilvægasti þátturinn er raunverulegur ARM64-prófunarumhverfi. Hermun getur í einstaka tilvikum hjálpað en kemur ekki í stað framkvæmdar með raunverulegri vélbúnaði, réttum driverum og öryggisstefnum.

Minnsta ARM64-smoke-próf: hvað skiptir máli snemma

Pragmatískt en áhrifaríkt smoke-test-set fyrir hverja release-kandidat-útgáfu:

• Upphaf forrits, innskráning, grunn UI-færni
• DB-tenging (m.a. auðkenning, vottorð, DNS/Proxy ef við á)
• Eitt kjarna-End-to-End ferli (t.d. stofna verk, vista, prenta/útflutning)
• Updater/Installer: ný uppsetning og uppfærsla yfir útgáfu
• Logging/villudialogar: nýtast greiningar á ARM64?

Þetta gerir typíska ARM64-blokkera sýnilega snemma: vantar DLLs, rangir driverar, setup-vandamál, óvænt réttindakrafa.

Greiningargeta: crash-dumps, logs, útgáfu-transparence

Þegar ARM64 er í flotanum munu koma support-mál – ekki síst vegna nýrra driver-samsetninga. Þess vegna borgar sig að staðla greiningar: skýrar build-IDs, lýsandi logs, endurleikjanlegar uppsetningar- og uppfærslu- leiðir. Þetta er ekki sérstakt fyrir ARM64, en ARM64 gerir skort á þessu fljótt kostnaðarsamt.

Rollout og rekstur: blandaðar flotur án kaosa

Mörg fyrirtæki munu á milli tíma reka blandaðar klient-flotur: hluti x64, hluti ARM64. Lykillinn er að móta þennan stöðufyrirfram meðvitað.

Pökkun: aðskildir installerar, skýr greining, ótvíræð niðurhalstengingar

Í framkvæmd virkar best þegar installerar/pakkar eru ótvíræðir: x64-pakki er x64, ARM64-pakki er ARM64. „Einn installer fyrir allt“ virðist þægilegur en verður fljótt flókinn (próflógík, forkröfur, driver-slóðir, skráning, viðgerð). Fyrir stjórnuð fyrirtækjarollout er ótvíræðni oft stöðugri leiðin.

Uppfærslu-stefna: engir sérleiðir fyrir ARM64

ARM64 ætti ekki að vera sértilvik í uppfærsluferlinu. Markmiðið: sama útgáfutíðni, sama fagútgáfunúmer, en aðskilin artifacts. Ef ARM64 er aðeins uppfærður „handvirkt“ myndast frávik í flotanum sem seinna hækka support-kostnað.

Skýr skjöl um samþættingar

Mörg ARM64-vandamál liggja ekki í eigin kóða heldur í samþættingum: ERP-connector, DMS-client, undirskriftarþjónusta, skannarhugbúnaður, merkimiða-prentarar. Uppfærð samþættingaskrá með útgáfum og arkitektúrupplýsingum er í B2B-kerfum eðlileg – og gerir ARM64-ákvarðanir gagnsærri.

Hvað fyrirtæki ættu að gera núna (án aðgerðasturs)

Að taka Windows 11 ARM64 snemma inn í áætlun þýðir ekki að rífa allt niður strax. Þýðir að svara réttum spurningum tímanlega og eyða blokkum meðan fjárfesting er áætlanleg. Reynd nálgun er:

• 1) Stöðumat (2–10 dagar eftir kerfisstærð): háðar, installer, driverar, gagnaaðgangur, COM, reporting.
• 2) Markmynd og leið: Hvað þarf að vera innfæddur á klient? Hvað fer í þjónustu/REST? Hvaða íhlutar verða skipta út?
• 3) Proof of Feasibility: gangandi ARM64-build með installer og end-to-end notkunardæmi.
• 4) Stigvaxandi hörðun: eftirliggjandi virkni, prófanir, update-keðja, greiningargeta.

Svo verður ekkert „ARM64-projekt“ sem gengur einangrað mánuðum saman, heldur stýrt útfærsla á afhendingargetu.

Niðurstaða: Windows 11 ARM64 er ekki tískubylgja heldur snemmbær mælikvarði á tæknilega þroska

Windows 11 ARM64 verður fyrir mörg fyrirtæki einfaldlega raunveruleiki – vegna vélbúnaðarkaupa, hreyfanleikakröfu eða staðlar. Fyrir Delphi-forrit er raunveruleg áskorun ekki bara aðlögun á kóðanum heldur heildarkerfið: háðir, uppsetningar- og uppfærsluferlar, samþættingar og driverar. Sá sem tekur ARM64 snemma getur kerfisbundið afmarkað þessi atriði í stað þess að „plástra“ þau undir tímapressu síðar.

Að lokum er ARM64 gagnlegur prófsteinn: Hversu vel er forritið þitt aðskilið, prófanlegt og afhendingarhæft? Ef þú svarar þeirri spurningu núna færðu ekki aðeins fleiri platforma-möguleika heldur líka stöðugari grunn fyrir moderniseringu, þjónustur, REST-arkitektúra og langtíma viðhald.

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.