Windows 11 ARM64 su Delphi įmonėse: parinktys, rizikos ir patikimas migracijos kelias

Windows įrenginiai su ARM64 CPU (ARM64 yra 64 bitų procesorių architektūra, žinoma iš mobiliųjų SoC ir vis dažniau naudojama verslo nešiojamuosiuose kompiuteriuose) daugelyje įmonių nebėra vien „egzotika“. Jie plinta per standartizuotas nešiojamųjų kompiuterių flotes, ilgesnę baterijos veikimo trukmę, naujas aparatinės įrangos saugumo funkcijas ir tiekimo grandinės strateginį diversifikavimą. Ne vėliau kaip tada, kai specialistų skyrius įsigyja naujus įrenginius arba OEM gamintojai tam tikrus modelius tiekia tik kaip Windows on ARM, IT atsakingiesiems praktiškai iškyla klausimas: kaip mūsų Delphi-pagrįsta verslo programinė įranga elgsis veikiant Windows 11 ARM64 – ir kaip užtikrinsime eksploatavimą, palaikymą ir tolesnį vystymą?

Svarbiausia: Windows 11 ARM64 su Delphi verslo aplinkoje yra ne tiek grynai vystymo klausimas, kiek priklausomybių, diegimo strategijų, tvarkyklių, sąsajų ir realaus elgesio lauke klausimas. Praktikoje yra trys keliai: tolesnis veikimas per emuliaciją, natyvūs ARM64 build’ai arba pereinamasis modelis, kuris rizikas kontroliuotai mažina. Šiame įraše išdėstomos tipinės kliūtys ir parodytas patikimas kelias, veikiantis IT planavime, diegime ir eksploatacijoje – be „viską iš naujo“ refleksų.

Warum Windows 11 ARM64 jetzt relevant wird

Windows on ARM nėra naujiena, bet pasikeitė kontekstas: įrenginiai tapo prieinami verslo aplinkoje, Windows 11 suteikia žymiai brandesnę x64 emuliaciją, o programinės įrangos tiekėjai vis dažniau tiekia ARM64 variantus. Įmonėms tai reiškia: ARM64 nebeišnyra kaip vienkartinis pilotinis projektas, o tampa platforma, įtraukiama į įsigijimo ir gyvavimo ciklo planavimą.

Procesams artimoms programinėms sprendimams problema nėra tiek pati CPU, kiek periferinės įrangos ir integracijos realybė: spausdintuvai, parašų kortelės, skeneriai, Office įskiepių priedai, COM komponentai (COM yra Microsoft komponentų modelis programų ir bibliotekų integracijai), shell plėtiniai, VPN klientai arba saugumo agentai. Jei bent vienas iš šių komponentų nėra suderinamas su ARM64, atsiranda palaikymo darbų – ir dažnai kaltinimas nukrypsta ant „programos“.

Einordnung: Was bedeutet ARM64 technisch für Delphi-Anwendungen?

Delphi programos verslo aplinkoje dažnai yra klasikiniai Windows darbalaukio klientai (dažnai VCL, t. y. Visual Component Library Windows GUI) su duomenų bazės prieiga (pvz. per BDE-pakeitimą su natyvia sąsaja, Delphi duomenų prieigos sluoksnį) ir su mišriu vietinių bei nuotolinių integracijų rinkiniu. Veikiant Windows 11 ARM64 išsiskiria trys vykdymo būdai:

1) Native ARM64-Ausführung

Programa ir visos natyvios bibliotekos (DLLs) yra pateiktos ARM64 formatu. Ilgalaikėje perspektyvoje tai švariausias sprendimas, nes jis užtikrina planuojamą našumą ir stabilumą ir pašalina emuliacijos sąlygas. Tačiau tai realu tik tuomet, kai visos natyvios priklausomybės perkeliamos: duomenų bazių tvarkyklės, spausdinimas/peržiūra, PDF variklis, kriptografijos bibliotekos, OCR/Scan SDK’ai, aparatūros donglių tvarkyklės ir kt.

2) x64-Emulation unter Windows 11 ARM64

Windows 11 gali emuliuoti x64 programėles. Daugelio grynai darbalaukio klientų atveju tai veikia stebėtinai gerai. Tačiau praktikoje emuliacija nėra „laisvas bilietas“: kai dalyvauja tvarkyklės, Shell integracijos ar in‑process komponentai (DLL, įkeliamos į procesą), sprendžia architektūra. x64 procesas negali įkelti ARM64 DLL ir atvirkščiai. Būtent ši riba dažnai lemia „veikia“ arba „neveikia“.

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

Vienas pereinamas kelias — kritines x64 komponentes ištraukti iš proceso: pvz. paleisti jas kaip išorinę paslaugą, kaip REST‑backend (REST yra HTTP pagrindu veikiantis sąsajų modelis) arba kaip atskirą pagalbinę programą. Tai mažiau elegantiška nei „viskas natūraliai“, bet dažnai ekonomiškiausias sprendimas užtikrinti veikimą ir palaipsniui modernizuoti priklausomybes.

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

Projekto metu greitai paaiškėja: problema dažniau yra ne GUI, o ekosistema. Struktūrizuota priklausomybių analizė čia sutaupo savaites bandymų ir klaidų.

Native DLLs und SDKs: Das unsichtbare Risiko

Daugelis Delphi programų integruoja trečiųjų šalių DLL: PDF kūrimas, Barcode/QR, vaizdų apdorojimas, šifravimas, proprietarinės komunikacijos bibliotekos. ARM64 atveju griežtai galioja: DLL turi atitikti proceso architektūrą. Emuliacija padeda tik tada, kai visas procesas lieka x64. Kai norima veikti natūraliai, šios bibliotekos turi būti pateiktos kaip ARM64 arba jas reikia pakeisti.

Praktinis patarimas IT: paprašykite programinės įrangos atsakingųjų pateikti sąrašą, kurių DLL yra diegimo kataloge ir kurios kraunamos per sistemos kelius. Tai yra pagrindas vertinant gamintojo palaikymą ir alternatyvas.

COM, Office-Automation und Shell-Erweiterungen

COM dažnai naudojamas įmonių kasdienybėje be tiesioginio paminėjimo: Outlook integracija, Excel eksportas per automatizaciją, DMS klientai, peržiūros tvarkyklės Explorer’yje, kontekstinio meniu plėtiniai. Problema ARM64 atveju nėra tiek pats COM, kiek architektūros (bitumo) priklausomybė: in‑process COM serveriai (COM komponentai, pagrįsti DLL) turi būti tos pačios architektūros. Out‑of‑process COM (EXE pagrįsti serveriai) yra lankstesni, nes gali veikti atskirame procese.

Jei jūsų Delphi programa, pavyzdžiui, naudoja seną 32‑bit ar 64‑bit COM DLL, tai natūraliai veikiant ARM64 bus esminė kliūtis. Emuliuojant kaip x64 tai gali veikti — tol, kol visos COM priklausomybės taip pat yra x64 ir į procesą neįsiterpia tik ARM64 komponentai.

Druck, PDF und Treiberlandschaft

Spausdinimo problemos yra klasika keičiant platformas. Dėl Windows 11 ARM64 lemiama, ar spausdintuvų gamintojas teikia ARM64 tvarkykles, arba ar galima naudoti Universal Print/IPP klasės tvarkykles (IPP yra standartizuotas spausdinimo protokolas). Taip pat PDF spausdintuvai, masinis spausdinimas, etikečių spausdinimas ir specialūs įrenginiai (pvz., terminiai spausdintuvai) gali priklausyti nuo tvarkyklių, kurios prieinamos tik x64.

IT vadovybei ir administracijai svarbi išvada: ARM64 diegimai turi būti derinami su spausdinimo strategija. „Programa nespauzdina“ dažnai reiškia „tvarkyklės nėra“ arba „spausdinimo vamzdis kitoks“.

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

Duomenų lygyje verta aiškiai atskirti protokolą ir klientinę biblioteką. BDE-Ablosung mit nativer Anbindung gali, priklausomai nuo duomenų bazės, dirbti su natyviomis klientų bibliotekomis arba su tvarkyklėmis. Pvz., jei reikalingas Oracle-klientas, senesnis PostgreSQL-klientas arba specifinė ODBC tvarkyklė, tai turi būti prieinama ARM64 versijoje – arba renkatės architektūrą, kuri duomenų prieigą kapsuliuoja serverio pusėje (pvz. per REST-services arba Windows-/Windows- ir Linux-Services).

Stabiliam veikimui tai yra esminis svertas: kuo mažiau darbalaukio klientas yra tiesiogiai susietas su duomenų bazės tvarkyklėmis ir vietiniais duomenų bazių rinkiniais, tuo paprasčiau pereiti prie ARM64. Tai taip pat aktualu saugumo požiūriu: duomenų bazės prisijungimo duomenis, sertifikatus ir tinklo taisykles galima nuosekliau valdyti serverio pusėje.

Kryptografija, išmaniosios kortelės, parašai, VPN, EDR

Daugelis verslo procesų šiandien priklauso nuo kriptografinių komponentų: S/MIME, kliento sertifikatai, smartcard-tarpinė programinė įranga, parašų kortelės, TLS-inspekcija per tarpinį serverį (proxy). Tam pridedami galinių taškų saugumo sprendimai (EDR — Endpoint Detection and Response) ir VPN klientai. Šios komponentės turi būti suderinamos su ARM64, kitaip kyla problema „įrenginys yra, bet negali prisijungti prie tinklo“.

Delphi programai tai reiškia: jei, pvz., naudojate sertifikatus iš Windows sertifikatų saugyklos arba TLS vykdote per sistemos komponentus, tai dažniausiai mažiau kritiška, nei kai procese dalyvauja specifinė trečios šalies kriptografinė DLL.

Sprendimų matrica: emuliacija ar natyvus ARM64 portavimas?

Įmonėms reikia sprendimo, atspindinčio palaikymo ir gyvavimo ciklo realijas. Paprastas taip/ne klausimas („Portuojame?“) retai būna naudingas. Geriau turėti matricą, kuri įvertintų priklausomybes ir rizikas:

• Grynas klientas su standartinėmis Windows API (failai, tinklas, spausdinimas per standartines tvarkykles): emuliacija gali pakakti trumpuoju laikotarpiu; natyvus ARM64 yra tvarkingas vidutinės trukmės sprendimas.
• Klientas su daug natyvių trečiųjų šalių DLL (PDF, OCR, aparatinė įranga): pirmiausia patikrinti prieinamumą, tada priimti sprendimą. Dažnai prasmingas hibridinis kelias.
• Klientas su COM-DLL ir shell plėtiniais: tikėtini architektūros konfliktai; patikrinkite proceso išorės atskyrimą.
• Klientas su daugybe tiesioginių DB tvarkyklių: arba konsoliduoti tvarkykles, arba perkelti duomenų prieigą į servisus.
• Aukšta reguliacija/parašai/išmaniosios kortelės: anksti patikrinkite saugumo ir tarpinės programinės įrangos grandinės suderinamumą su ARM64.

Svarbu: emuliacija nėra „antroji rūšis“, bet ji yra einamojo eksploatavimo rizika, jei ilgainiui jūsų įrenginių parke matote ARM64 įrenginius. Vėliausiai didesnių atnaujinimų, tvarkyklių pakeitimų ar saugumo agentų kaitos metu nenorėsite likti su specialių atvejų grandine.

Patikimas migracijos kelias: nuo šiandien prie ARM64 be vienkartinio didelio perėjimo

IT ir projektų vadovams kelias tinkamas, jei jis diegiamas bangomis, turi aiškius priėmimo kriterijus ir neperkrauna palaikymo. Delphi aplinkose pasiteisino penkių žingsnių veiksmų planas.

1. žingsnis: Inventorizacija su „eksploatacijos akiniu“

Užfiksuokite ne tik modulius, bet ypač eksploatacinius taškus:

• Kokios įrenginių klasės: nešiojamieji kompiuteriai, atsparūs įrenginiai (Rugged Devices), terminalai?
• Kokia periferinė įranga: spausdintuvai, skaitytuvai, kortelių skaitytuvai, etikečių spausdintuvai?
• Kokios integracijos: Office, DMS, ERP, vietinės paslaugos, naršyklės komponentai?
• Kokia diegimo forma: MSI, Setup-EXE, ClickOnce, rankinis talpinimas?
• Kokios teisės: ar reikalingas administratorius, vietiniai servisai, ugniasienės taisyklės?

Šis vaizdas greitai parodo, ar „tik vienas klientas“ iš tiesų reiškia penkias sistemos priklausomybes.

Schritt 2: Kompatibilitätscheck mit repräsentativem ARM64-Pilot

Pilotas neturėtų būti „gražiausias įrenginys“, o tipinis kandidatas iš tikslinės flotilės. Testuokite sąmoningai kritinius kelius: spausdinimas visomis variacijomis, eksportas/importas, skaitmeninis parašas, offline/online režimai, atnaujinimai, nuomininko perjungimas, proxy/VPN scenarijai. Nukrypimus dokumentuokite kaip eksploatacinius įvykius, o ne kaip kūrėjų klaidas. Taip prioritetai lieka aiškūs.

Schritt 3: Abhängigkeiten reduzieren – zuerst die mit hohem Supporthebel

Tipiški veiksmai, kurie kasdienėje praktikoje duoda daug naudos:

• PDF-/spausdinimo kelio standartizavimas: pereiti nuo proprietarių spausdintuvų DLL prie stabilių, patikrintų procesų.
• Office integracijos atjungimas: vietoje In-Process-Add-ins geriau svarstyti eksporto formatus ir serverinę dokumentų generaciją.
• Duomenų bazės prieigos konsolidavimas: vienas apibrėžtas tvarkyklės kelias vietoje „ODBC priklausomai nuo darbo vietos“.
• Įrenginių prijungimų kapsuliavimas: jei įmanoma – per išorinius procesus/paslaugas, kurias galima atnaujinti atskirai.

Schritt 4: Deployment und Updatefähigkeit modernisieren

ARM64 yra gera proga sutvarkyti diegimą ir atnaujinimus. Įmonėms čia svarbu ne funkcionalumas, o atkūrimo galimybė, pakartojamumas ir politikos atitiktis. Patikrinkite:

• Paketavimas: MSI vs. MSIX (MSIX yra Microsoft modernus programų paketo formatas su švaria diegimo/išdiegimo eiga ir parašu).
• Pasirašymas: Code Signing (EXE/DLL skaitmeninis parašas) mažina SmartScreen ir EDR trintį ir yra svarbus kontroliuojamiems roll-out’ams.
• Konfigūracijos valdymas: programinių failų ir konfigūracijos atskyrimas, aiškios vietos, jokių „paslėptų“ Registry priklausomybių.
• Atnaujinimų kanalai: Pilotas, Ring 1, Ring 2 – su telemetrija/logavimu tiek programos, tiek operacijų lygiu.

Schritt 5: Native ARM64 dort, wo es sich wirklich lohnt

Gimtieji ARM64 build’ai prasmingi tada, kai (a) valdote priklausomybes ir (b) programą ketinate ilgalaikiam vystymui. Dažniausiai tai apsimoka pagrindiniuose klientuose, kuriuos daug vartotojų naudoja kasdien ir kuriuos vis tiek modernizuosite. Retai naudojamiems įrankiams x64 emuliacija gali būti priimtinas pereinamasis sprendimas, kol palaikymas ir saugumas tai leidžia.

Architektūriniai impulsai: ARM64 kaip proga stiprinti sąsajas ir paslaugas

Daugelis Delphi-landšaftų istoriškai išaugo kaip „storas klientas“. Tai veikia, bet tai susieja eksploatavimą ir atnaujinimus stipriau su konkrečiomis darbo vietos konfigūracijomis. ARM64 parodo, kur ši susiejimo kaina tampa didele. Pragmatiškas modernizavimo žingsnis todėl dažnai nebūna „UI naujas“, o sąsajų atnaujinimas.

Didesnis stabilumas per serverio pusės atsakomybes

Kai kritinė logika, duomenų prieiga ar dokumentų procesai perkeliami į centralizuotą paslaugą (Windows- ir Linux-paslaugos arba Linux-paslauga, t. y. foninė paslauga be interaktyvios vartotojo sąsajos), įgyjate:

• vienodesnes tvarkyklių ir bibliotekų versijas,
• geriau kontroliuojamą saugą (sertifikatai, slaptos reikšmės, tinklas),
• mažesnę sudėtingumą kliento pusėje (ARM64, x64, ateityje ir kitos platformos),
• aiškesni monitoringo ir žurnalo (logging) taškai.

IT sprendimų priėmėjams tai yra realus eksploatacijos pranašumas: problemos serveryje tampa greičiau atkartojamos, užuot priklausiusios nuo „specialaus nešiojamojo kompiuterio“.

REST-API kaip atskyrimo sluoksnis

REST-API nėra automatiškai „moderni“, bet tai tvirta atskyrimo tarp klientų ir backend’o priemonė. Ji aiškiai apibrėžia, kokie duomenys ir veiksmai leidžiami, ir gali būti patikimai apsaugota (pvz., per tokenus, sertifikatus arba SAML 2.0 kaip tapatybės standartą įmonių aplinkose). ARM64 atveju tai reiškia: klientas turi mažiau „bendrų žinių“ apie duomenų bazes, tvarkykles ir tinklo detales.

Net jei nedelsdami visko nekeisite: jau mažas, gerai apribotas API modulis (pvz., dokumentų generavimas, licencijų patikra, pagrindinių duomenų sinchronizacija) gali pašalinti priklausomybes iš kliento ir taip sumažinti ARM64 rizikas.

Testavimas ir kokybė: ką ARM64 atveju reikėtų tikrinti kitaip

Daugelis komandų testuoja darbalaukio programinę įrangą daugiausia funkciniu požiūriu. ARM64 atveju verta stipriau orientuotis į eksploatacinį testavimą, nes klaidų vaizdai skiriasi: ne „klaidingas skaičiavimas“, o „komponentas neužkraunamas“, „trūksta tvarkyklės“, „atnaujinimas nepavyksta“, „Office integracija nutrūksta“.

Kontrolinis sąrašas ARM64 priėmimui

• Diegimas/šalinimas: švarus, be likučių, be administratoriaus įsikišimo ar laikinių sprendimų.
• Atnaujinimo kelias: atnaujinimas per kelias versijas, grąžinimo (rollback) scenarijus, parašo patikra.
• Žurnalai (Logging): centriniai žurnalai, aiškūs klaidų kodai DLL užkrovos problemų atveju, atsekami spausdinimo keliai.
• Veikimas: paleidimo laikas, duomenų operacijos, didelės lentelės/ataskaitos – emuliacijoje ir natyviai atskirai matuoti.
• Periferija: spausdintuvo profiliai, specialus spausdinimas, skenerių darbo eiga, išmaniųjų kortelių funkcijos.
• Saugumas: EDR/AV sąveika, proxy/TLS, sertifikatų saugykla, mažiausių privilegijų principo taikymas.

Svarbi yra dokumentacija: jeigu problema kyla dėl trūkstamų ARM64 tvarkyklių, tai nėra „klaidos taisymas Delphi“, o įsigijimo arba standartizavimo sprendimas.

Eksploatavimas ir palaikymas: kaip integruoti ARM64 į kasdienę veiklą

Kasdienybėje svarbiausia, kaip greitai sprendžiami palaikymo atvejai. ARM64 atveju verta proaktyviai didinti palaikymo galimybes:

Standartizuoti įrenginių profiliai ir aiškūs patvirtinimai

Apibrėžkite palaikomus ARM64 modelius arba bent minimalius profilius (tvarkyklių strategija, spausdinimo strategija, saugumo agente versijos). Teiginys „veikia ARM64“ be tokio konteksto veda prie nevienodų aplinkų ir sunkiai atkartojamų sutrikimų.

Diagnostikos galimybės programoje

Net be kūrėjų dėmesio programai, aiškus reikalavimas yra grindžiamas: sistemos informacijos puslapis, rodantis architektūrą (x64 emuliuota vs. ARM64 natyvi), svarbius kelius, pagrindinių komponentų versijas ir spausdinimo konfigūraciją, žymiai sumažina palaikymo trukmę. Tai nėra „nice to have“, o eksploatacijos higiena.

Licencijavimas ir donglai

Jeigu naudojami aparatūros donglai arba senesni licencijų tvarkyklės, ARM64 greitai tampa kritiškas. Daugelyje aplinkų prasminga perkelti licencijavimą į tinklo palaikomus arba serverinius mechanizmus. Tai sumažina priklausomybę nuo tvarkyklių galutiniuose įrenginiuose ir padaro įrangos parką lengviau keičiama.

Ką tai reiškia jūsų Delphi strategijai?

Delphi įmonės kontekste dažnai yra stabilus elementas darbalaukio klientams ir paslaugoms. Windows 11 ARM64 nėra argumentas „prieš Delphi“, bet yra argumentas už švaresnį priklausomybių kapsuliavimą ir už operacijomis grįstą modernizavimą: mažiau vietinių specialių tvarkyklių, mažiau in-process komponentų, aiškesnės sąsajos, geresnis diegimas.

Jeigu jau esate modernizacijos kelyje (pvz. BDE-Ablösung, pereinant prie 64 bitų, stipresnė REST integracija, konsoliduotas duomenų prieigos modelis su FireDAC), tai ARM64 dažnai būna „tik“ papildomas tikslas, susiaurinantis prioritetus. Jei jūsų taikymas stipriai priklauso nuo senų tvarkyklių, proprietarinių DLL ir darbo vietos specialių konfigūracijų, ARM64 yra tinkama proga šias rizikas atskleisti ir planingai sumažinti.

Išvada: ARM64 – mažiau portavimo projektas, daugiau architektūros ir eksploatacijos projektas

Įmonėms Windows 11 ARM64 pirmiausia yra platformos klausimas pirkimų, saugumo ir palaikymo kontekste. Delphi pagrįstai verslo programinei įrangai sėkmė nepriklauso nuo kompiliatoriaus parinkties, o nuo grandinės: tvarkyklės, DLL, COM integracijos, duomenų prieiga ir atnaujinimo procesai. Patikimas kelias yra toks: pirmiausia padaryti matomas priklausomybes ir eksploatacijos takus, tada išbandyti su pilotiniais įrenginiais, vėliau tikslingai atsieti komponentus ir profesionalizuoti diegimą – ir tiekti natyvias ARM64 versijas ten, kur jos ilgalaikėje perspektyvoje duoda naudą ir stabilumą.

Jeigu norite įdiegti Windows 11 ARM64 savo flotėje ir tuo pačiu planuotai apsaugoti Delphi programas, periferiją bei sąsajas, susisiekite su mumis dėl struktūrizuotos esamos būklės inventorizacijos ir realistiško migracijos kelio:

Profesinėje aplinkoje taip pat svarbų vaidmenį atlieka Delphi ARM64 Windows ir X64-emuliacija Windows 11, kai integracijos, duomenų srautai ir tolesnis vystymas turi veikti sklandžiai kartu.

Aptarti projektą arba modernizacijos užduotį su Net-Base.