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

Windows-įrenginiai su ARM64 CPU (ARM64 yra 64 bitų procesoriaus architektūra, žinoma iš mobiliųjų SoC ir vis dažniau naudojama verslo nešiojamuosiuose kompiuteriuose) daugelyje įmonių nebėra vien tik „eksotika“. Jie atsiranda dėl standartizuotų nešiojamųjų kompiuterių parkų, ilgesnės baterijos veikimo trukmės, naujų aparatūros saugumo funkcijų ir tiekimo grandinės strateginės diversifikacijos. Anksčiau ar vėliau, kai padaliniai įsigyja naujus įrenginius arba OEM gamintojai tam tikrus modelius siūlo tik kaip Windows on ARM, IT atsakingiesiems kyla praktiškas klausimas: kaip mūsų Delphi-pagrįsta verslo programinė įranga elgsis su Windows 11 ARM64 – ir kaip užtikrinsime eksploatavimą, palaikymą ir tolesnę plėtrą?

Pagrindinė mintis yra tokia: Windows 11 ARM64 su Delphi įmonėse yra ne tiek grynai vystymo klausimas, kiek priklausomybių, įdiegimo strategijų, tvarkyklių, sąsajų ir realaus elgesio lauke klausimas. Praktikoje yra trys keliai: tęsti veikimą per emuliaciją, kurti natyvius ARM64 leidimus arba naudoti pereinamąjį modelį, kuris kontroliuojamai mažina rizikas. Šis straipsnis išskirsto tipines kliūtis ir pateikia patikimą kelią, veikiančią IT planavime, diegime (rollout) ir eksploatacijoje – be „viską iš naujo“ reflekso.

Kodėl Windows 11 ARM64 dabar tampa aktualus

Windows on ARM nėra naujiena, tačiau aplinkybės pasikeitė: įrenginiai prieinami verslo aplinkoje, Windows 11 suteikia žymiai subrendusį x64 emuliavimą, o programinės įrangos tiekėjai vis dažniau tiekia ARM64 variantus. Įmonėms tai reiškia: ARM64 nebeišryškėja kaip vienkartinis pilotinis projektas, o kaip platforma, įtraukiama į pirkimų ir gyvavimo ciklo planavimą.

Procesinėms programų sprendimams problema dažniau yra ne pati CPU, o periferijos ir integracijos realybė: spausdintuvai, parašų kortelės, skeneriai, Office papildiniai, COM komponentai (COM yra Microsoft komponentų modelis programų ir bibliotekų integracijai), Shell plėtiniai, VPN klientai ar saugumo agentai. Jei kas nors iš jų nėra pritaikyta ARM64, atsiranda palaikymo apkrova – ir dažnai tuomet kaltinama „programa“.

Klasifikacija: Ką ARM64 techniniu požiūriu reiškia Delphi programoms?

Delphi programos įmonių aplinkoje dažnai yra klasikiniai Windows darbalaukio klientai (dažnai VCL, tai yra Visual Component Library skirta Windows GUI) su duomenų bazės prieiga (pvz. per BDE-pakeitimas su natyviu prijungimu, Delphis duomenų prieigos sluoksnis) ir vietinių bei nuotolinių integracijų mišiniu. Su Windows 11 ARM64 išsiskiria trys vykdymo režimai:

1) Natyvus ARM64 vykdymas

Programa ir visos natyvios bibliotekos (DLLs) pateikiamos ARM64 formatu. Tai ilgalaikėje perspektyvoje yra techniškai švariausias sprendimas, nes leidžia planuoti našumą ir stabilumą bei išvengti emuliacijos ribojimų. Tačiau tai realu tik tuomet, jei visos natyvios priklausomybės taip pat palaiko ARM64: duomenų bazės tvarkyklės, spausdinimo/peržiūros sprendimai, PDF variklis, kriptografijos bibliotekos, OCR/Scan-SDKs, aparatūros donglių tvarkyklės ir kt.

2) x64-Emuliacija su Windows 11 ARM64

Windows 11 kann x64-Anwendungen emulieren. Für viele reine Desktop-Clients funktioniert das überraschend gut. In der Praxis ist Emulation aber keine „Freikarte“: Sobald Treiber, Shell-Integrationen oder In-Process-Komponenten (DLLs, die in den Prozess geladen werden) beteiligt sind, kommt es auf die Architektur an. Ein x64-Prozess kann keine ARM64-DLL laden und umgekehrt. Genau diese Grenze entscheidet häufig über „läuft“ oder „läuft nicht“.

3) Hibridas: ARM64 klientas, x64 komponentų atskyrimas

Vienas pereinamojo kelio variantų yra ištraukti kritines x64 komponentes iš proceso: pvz., kaip išorinę paslaugą, kaip REST-backend (REST ist ein HTTP-basiertes Schnittstellenmodell) oder als separates Hilfsprogramm. Das ist weniger elegant als „alles nativ“, aber oft die wirtschaftlichste Route, um Betrieb zu sichern und Abhängigkeiten schrittweise zu modernisieren.

Windows 11 ARM64 su Delphi įmonėse: tipinės priklausomybės, nuo kurių priklauso sėkmė

Projektais greitai paaiškėja: kliūtis dažniau būna ne GUI, o ekosistema. Struktūruota priklausomybių analizė sutaupo čia savaites bandymų ir klaidų.

Gimtosios DLL ir SDK: nematoma rizika

Daugelis Delphi-programų įtraukia trečiųjų šalių DLL: PDF generavimas, brūkšninių kodų/QR apdorojimas, vaizdų apdorojimas, šifravimas, patentuotos komunikacijos bibliotekos. ARM64 aplinkoje galioja griežta taisyklė: DLL turi atitikti proceso architektūrą. Emuliacija padeda tik tada, kai visas procesas lieka x64. Kai norima veikti natūraliai (nativiai), šios bibliotekos turi būti ARM64 arba jas reikia pakeisti.

Praktinis patarimas IT: paprašykite programinės įrangos atsakingo asmens pateikti sąrašą, kurios DLL yra diegimo kataloge ir kurios kraunamos per sistemos kelius. Tai pagrindas gamintojų pajėgumui ir alternatyvoms įvertinti.

COM, Office automatizacija ir Shell plėtiniai

COM dažnai naudojamas įmonių kasdienybėje, net jei taip nevadinamas: Outlook integracija, Excel eksportas per automatizaciją, DMS klientai, peržiūros tvarkyklės Explorer yje, kontekstinio meniu plėtiniai. Problema ARM64 nėra tiek COM kaip toks, kiek bitumo susiejimas: in-process COM serveriai (DLL pagrįstos COM komponentės) turi turėti tokią pačią architektūrą. Out-of-process COM (EXE pagrįsti serveriai) lankstesnis, nes gali veikti atskirame procese.

Jei jūsų Delphi programa, pavyzdžiui, naudoja seną 32‑Bit- oder 64‑Bit-COM-DLL, tai nativiai veikiant ARM64 tai bus kliūtis. Emuliert als x64 kann es funktionieren – solange alle COM-Abhängigkeiten ebenfalls x64 sind und keine ARM64-only-Teile hineingreifen.

Spausdinimas, PDF ir tvarkyklių ekosistema

Spausdinimo problemos yra klasika keičiant platformą. Unter Windows 11 ARM64 ist entscheidend, ob der Druckerhersteller ARM64-Treiber bereitstellt oder ob Universal Print/IPP-Klassen-Treiber (IPP ist ein standardisiertes Druckprotokoll) genutzt werden können. Auch PDF-Drucker, Stapeldruck, Etikettendruck und Spezialgeräte (z. B. Thermodrucker) können an Treibern hängen, die es nur für x64 gibt.

IT vadovybei ir administracijai svarbi išvada: ARM64-Rollouts müssen mit der Druckstrategie abgestimmt werden. „Die Anwendung druckt nicht“ ist oft „der Treiber existiert nicht“ oder „die Druckpipeline ist anders“.

Duomenų prieiga: FireDAC, ODBC/OLE DB und Datenbank-Clients

Duomenų lygyje verta aiškiai atskirti protokolą ir kliento 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 specifinis ODBC tvarkyklė, jis turi būti prieinamas kaip ARM64 – arba renkatės architektūrą, kuri duomenų prieigą kapsuliuoja serverio pusėje (pvz., per REST-paslaugas arba Windows-/ Windows- ir Linux-paslaugas).

Stabiliam veikimui tai yra esminis svertas: kuo mažiau darbalaukio klientas tiesiogiai priklauso nuo duomenų bazių tvarkyklių ir vietinių duomenų bazių „stektų“, tuo lengviau pasiekti ARM64. Tai taip pat aktualu saugumo prasme: duomenų bazės prisijungimo duomenis, sertifikatus ir tinklo taisykles galima nuosekliau valdyti serverio pusėje.

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

Daugelis verslo procesų šiandien remiasi kriptografinėmis komponentėmis: S/MIME, kliento sertifikatai, išmaniųjų kortelių tarpinė programinė įranga, parašų kortelės, TLS apžiūra proxy serveriuose. Prie to prisideda galutinio taško saugumo sprendimai (EDR reiškia Endpoint Detection and Response) ir VPN klientai. Šios komponentės turi būti suderinamos su ARM64, priešingu atveju kyla situacija „įrenginys yra, bet negali prisijungti prie tinklo“.

Delphi-taikymui tai reiškia: jei, pavyzdžiui, naudojate sertifikatus iš Windows-sertifikatų saugyklos arba vykdote TLS per sistemos komponentus, tai dažniausiai yra mažiau kritiška nei situacija, kai procese pakabinta specifinė trečiosios šalies kriptinė DLL.

Sprendimų matrica: emuliacija ar natyvi ARM64 portavimas?

Įmonėms reikia sprendimo, atspindinčio palaikymo ir gyvavimo ciklo realybę. Paprastas klausimas taip/ne („Ar mes portuojame?“) retai būna naudingas. Naudingesnė yra matrica, kuri įvertina priklausomybes ir rizikas:

• Grynasis klientas su standartinėmis Windows-API (failai, tinklas, spausdinimas per standartines tvarkykles): emuliacija gali pakakti trumpuoju laikotarpiu; natyvus ARM64 sprendimas yra tvarkingas vidutinės trukmės perspektyvoje.
• Klientas su daug natyvių trečiųjų šalių DLL (PDF, OCR, aparatinė įranga): pirmiausia patikrinkite prieinamumą, tada priimkite sprendimą. Dažnai prasmingas hibridinis kelias.
• Klientas su COM-DLL ar shell plėtiniais: tikėkitės architektūrinių konfliktų; įvertinkite out-of-process atskyrimą.
• Klientas su tiesiogine DB tvarkyklių įvairove: arba konsoliduokite tvarkykles, arba perkelkite duomenų prieigą į paslaugas.
• 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 „antros klasės“ sprendimas, tačiau ji yra einamojo eksploatavimo rizika, jei ilgainiui flotoje matote ARM64 įrenginius. Bent jau prie didesnių atnaujinimų, tvarkyklių pakeitimų ar saugumo agento keitimo nenorėsite remtis išimčių grandine.

Tvirtas migracijos kelias: nuo šiandien prie ARM64 be vienkartinio didelio perėjimo („Big Bang“)

IT ir projektų atsakingiesiems kelias yra geras, kai jis gali būti diegiamas bangomis, turi aiškius priėmimo kriterijus ir neperkrauna palaikymo. Delphi aplinkose pasiteisino penkių žingsnių metodas.

Žingsnis 1: Inventorizacija su „eksploatacijos požiūriu“

Fiksuokite ne tik modulius, bet pirmiausia eksploatacijos taškus:

• Kokios įrenginių klasės: nešiojamieji kompiuteriai, atsparūs įrenginiai (Rugged Devices), terminalai?
• Kokia periferinė įranga: spausdintuvai, skeneriai, 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 diegimas?
• Kokios teisės: ar reikalingos administratoriaus teisės, vietiniai servisai, ugniasienės taisyklės?

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

2 žingsnis: suderinamumo patikra su reprezentatyviu ARM64 pilotu

Pilotas neturėtų būti „gražiausias įrenginys“, o tipinis kandidatas iš tikslinės flotos. Sąmoningai išbandykite kritinius kelius: spausdinimą visomis variacijomis, eksportą/importą, parašą, offline/online režimus, atnaujinimus, mandantų perjungimą, Proxy/VPN scenarijus. Dokumentuokite nukrypimus kaip eksploatacijos įvykius, o ne kaip kūrėjų klaidas. Taip prioritetizavimas išlieka aiškus.

3 žingsnis: priklausomybių mažinimas – pirmiausia tos, kurios turi didelį palaikymo svertą

Tipiški veiksmai, kurie kasdieniame darbe duoda daug naudos:

• PDF-/spausdinimo kelio standartizavimas: pereikite nuo proprietariškų spausdintuvo DLL prie stabilios, ištestuotos spausdinimo grandinės.
• Office integracijos atsiejimas: vietoje procesų viduje veikiančių priedų geriau tikrinti eksportų formatus ir serverinį dokumentų generavimą.
• DB prieigos konsolidavimas: vienas apibrėžtas tvarkyklės kelias vietoje „ODBC pagal darbo vietą“.
• Aparatūros prijungimo kapsuliavimas: jei įmanoma, per išorinius procesus/paslaugas, kurias galima atnaujinti atskirai.

4 žingsnis: modernizuoti diegimą ir atnaujinimų galimybes

ARM64 yra gera proga išvalyti diegimą ir atnaujinimus. Įmonėms čia svarbūs ne funkcionalumai, o gebėjimas atšaukti pakeitimus (rollback), atkuriamumas ir atitiktis politikoms. Patikrinkite:

• Pakavimas: MSI vs. MSIX (MSIX yra Microsoft modernus programų paketų formatas su švariu diegimu/išdiegimu ir parašais).
• Pasirašymas: kodo pasirašymas (Code Signing, skaitmeninis EXE/DLL parašas) mažina SmartScreen ir EDR trintį ir yra svarbus kontroliuojamiems roll-outams.
• Konfigūracijos valdymas: programinių failų ir konfigūracijos atskyrimas, aiškūs keliai, jokios „paslėptos“ Registry priklausomybės.
• Atnaujinimų kanalai: Pilot, Ring 1, Ring 2 – su telemetrija ir logging’u tiek programos, tiek operacijų lygyje.

5 žingsnis: natyvūs ARM64 build’ai ten, kur tai iš tikrųjų apsimoka

Natyvūs ARM64 build’ai prasmingi, jei (a) priklausomybės yra valdomos ir (b) programą ketinate ilgalaikiškai plėtoti. Paprastai tai apsimoka pagrindiniams klientams, kuriuos daug vartotojų naudoja kasdien ir kuriuos vis tiek modernizuojate. Retai naudojamiems įrankiams x64 emuliacija gali būti priimtinas pereinamasis sprendimas, jei palaikymas ir saugumas tam pritars.

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

Daugelis Delphi aplinkų istoriškai išaugo kaip „dicker Client“. Tai veikia, bet stipriai susieja eksploatavimą ir atnaujinimus su atskiromis darbo vietos konfigūracijomis. ARM64 parodo, kur ši priklausomybė tampa brangi. Todėl pragmatiškas modernizavimo žingsnis dažnai nėra „UI naujinimas“, o sąsajų pertvarka.

Daugiau stabilumo perkeliant atsakomybes į serverio pusę

Jei kritinė logika, duomenų prieiga ar dokumentų procesai perkeliami į centralizuotą paslaugą (Windows- ir Linux-paslaugos arba Linux-paslauga, t. y. fono paslauga be interaktyvios UI), įgyjate:

• vienodesnius tvarkyklių ir bibliotekų lygius,
• geriau kontroliuojamą saugumą (sertifikatai, slaptiniai, tinklas),
• mažesnę kliento sudėtingumą (ARM64, x64, ateityje ir kitos platformos),
• aiškesni stebėjimo ir žurnalo (logging) taškai.

IT sprendimų priėmėjams tai tikras eksploatacijos privalumas: problemos serverinėje pusėje tampa greičiau atkartojamos, užuot užsilikusios „ant kokio nors specialaus nešiojamojo kompiuterio“.

REST-API kaip atjungimo sluoksnis

REST-API neautomatiškai reiškia „moderni“, bet tai tvirtas atskyrimo sluoksnis tarp klientų ir backend. Ji aiškiai apibrėžia, kokie duomenys ir veiksmai yra leidžiami, ir gali būti saugiai apsaugota (pvz., per token’us, sertifikatus arba SAML 2.0 kaip tapatybės standartą įmonės aplinkose). ARM64 atveju tai reiškia: klientui reikia turėti mažiau „visuotinės žinios“ apie duomenų bazes, tvarkykles ir tinklo detales.

Net jei nedarysite visko iš karto: jau mažas, gerai apibrėžtas API modulis (pvz., dokumentų generavimas, licencijų tikrinimas, pagrindinių duomenų sulyginimas) gali pašalinti priklausomybes iš kliento ir taip sumažinti ARM64 rizikas.

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

Daugelis komandų darbalaukio programinę įrangą testuoja pirmiausia funkcionaliai. ARM64 atveju reikėtų daugiau eksploatacinių testų, nes klaidų pobūdis kitoks: ne „neteisingas skaičiavimas“, o „komponentas nesikrauna“, „trūksta tvarkyklės“, „atnaujinimas nepavyksta“, „Office integracija nutrūksta“.

Patikrinimo sąrašas priėmimui, orientuotam į ARM64

• Įdiegimas/Pašalinimas: švariai, be liekanų, be administratoriaus apeidimų.
• Atnaujinimo kelias: atnaujinimas per kelias versijas, atsitraukimo (rollback) scenarijus, parašo tikrinimas.
• Žurnalai (Logging): centralizuoti žurnalai, aiškūs klaidų kodai DLL įkėlimo problemoms, atsekami spausdinimo keliai.
• Veikimas (Performance): paleidimo laikas, duomenų operacijos, didelės eilės/ataskaitos – matuoti atskirai emuliacijoje ir natyviai.
• Periferija: spausdintuvų profiliai, specialus spausdinimas, skenerių darbo eiga, išmanios kortelės funkcijos.
• Saugumas: EDR/AV sąveika, Proxy/TLS, sertifikatų saugykla, mažiausių teisių principo vykdymas.

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

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

Kasdienybėje svarbu, kaip greitai sprendžiami palaikymo atvejai. ARM64 atveju verta proaktyviai didinti palaikymo pajėgumą:

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

Apibrėžkite palaikomus ARM64 modelius arba bent minimalius profilius (tvarkyklių strategija, spausdinimo strategija, saugumo agento versijos). „Veikia ant ARM64“ be šio konteksto sukuria nenuoseklias aplinkas ir taip sunkiai atkartojamas trikdžių situacijas.

Diagnozės galimybės programoje

Net ir be kūrėjo dėmesio programai verta aiški funkcija: sistemos informacijos puslapis, nurodantis architektūrą (x64 emuliuota vs. ARM64 natyvi), svarbius kelius, pagrindinių komponentų versijas ir spausdinimo konfigūraciją, žymiai sutrumpina palaikymo laikus. Tai nėra „nice to have“, o eksploatacijos higiena.

Licencijavimas ir donglai

Jei naudojami aparatiniai donglai arba senesni licencijų tvarkyklės, ARM64 greitai tampa kritiškas. Daugelyje aplinkų prasminga perkelti licencijavimą į tinklinius arba serverinę mechaniką. Tai sumažina priklausomybę nuo tvarkyklių galiniuose įrenginiuose ir padaro įrenginių parką lengviau keičiama.

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

Delphi yra įmonių kontekste dažnai stabilus komponentas darbastalių klientams ir paslaugoms. Windows 11 ARM64 nėra argumentas „prieš Delphi“, bet argumentas už švaresnį priklausomybių kapsuliavimą ir už eksploatacijos orientuotą modernizavimą: mažiau vietinių specialių tvarkyklių, mažiau In-Process-komponentų, aiškesnės sąsajos, geresnis diegimas.

Jei jau esate modernizacijos kelyje (pvz. BDE-Ablösung, perėjimas prie 64 bitų, stipresnė REST integracija, konsoliduotas duomenų prieigos sprendimas su FireDAC), tai ARM64 dažnai yra „tiesiog“ papildomas tikslas, kuris aiškina prioritetus. Jei jūsų programa ryškiai priklauso nuo senų tvarkyklių, patentuotų DLL ir darbo vietų specialių konfigūracijų, ARM64 yra pagrįstas impulsyvas šias rizikas padaryti matomas ir planingai mažinti.

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

Įmonėms Windows 11 ARM64 iš esmės yra platformos klausimas pirkimų, saugumo ir palaikymo srityse. Delphi pagrįstai verslo programinei įrangai sėkmė nenumatoma kompiliatoriaus parinktimis, o priklausomybių grandine: tvarkyklės, DLL, COM integracijos, duomenų prieiga ir atnaujinimų procesai. Patikimas kelias: pirmiausia padaryti matomas priklausomybes ir eksploatacijos kelius, tada išbandyti su pilotinėmis įrenginėmis, vėliau tikslingai atsieti komponentus ir profesionalizuoti diegimą – ir tiekti natyvius ARM64 build’us ten, kur jie ilgalaikėje perspektyvoje duoda naudą ir stabilumą.

Jei norite įdiegti Windows 11 ARM64 savo parke ir tuo pačiu planuoti Delphi programas, periferiją ir sąsajas, susisiekite su mumis dėl struktūruotos inventorizacijos ir realistiško migracijos kelio:

Profesiniame kontekste taip pat svarbų vaidmenį atlieka Delphi ARM64 Windows ir X64 emuliacija Windows 11, kai integracijos, duomenų srautai ir tolesnis vystymas turi veikti sklandžiai.

Aptarkite projektą ar modernizacijos užmojus su Net-Base.