Windows 11 ARM64 korai ütemezése Delphi-alkalmazásokhoz

Windows 11 ARM64 a B2B-napi gyakorlatban már nem csupán a technikai rajongók különleges esete. Az új notebook-generációk, meghosszabbodott akkumulátor-üzemidők, „always-on” forgatókönyvek és a könnyű, mobil munkahelyek iránti növekvő igény arra késztetik a vállalatokat, hogy ARM64-kliens gépeket vásároljanak – néha tudatosan, máskor a keretszerződés szerinti standard modellek mellékhatásaként. Azoknál a csapatoknál, amelyeknél egy évek alatt felépített egyedi szoftver áll, ez egyértelmű üzenet: ARM64-nek korán be kell kerülnie a műszaki tervezésbe, különben később költséges utólagos projekt lesz belőle.

Delphi-alkalmazásoknál ritkán az a központi kérdés, hogy „le tudja-e Delphi fordítani?”. A gyakorlatban az ARM64-telepítések majdnem mindig a periférián buknak el: natív DLL-ek, nyomtató-/szkennelő-komponensek, adatbázis-illesztők, riportmotorok, COM-integrációk, telepítő-rutinok, kódfirmázás vagy build-pipelinek miatt, amelyek hallgatólagosan csak x64-et ismernek. Éppen ezért érdemes Windows 11 ARM64-t architektúrális és üzemeltetési követelményként kezelni – nem pusztán platformfunkcióként.

Ez a cikk bemutatja, mely műszaki buktatók jelentkeznek tipikusan Delphi-nél, hogyan azonosíthatja rendszeresen a kockázatokat és mely pragmatikus migrációs utak váltak be – az egyes modulok lépésenkénti alkalmassá tételétől a szolgáltatásokkal és REST-szerverekkel támogatott célarchitektúráig.

Miért architekturális téma most Windows 11 ARM64

Sok vállalatnál a „Windows” régóta egyet jelentett az x86/x64-gyel. Ez a feltevés beágyazódik scriptjeibe, telepítőibe, harmadik fél komponenseibe és néha még az adatmodellbe is (például elérési utak, Registry-kulcsok, illesztőfelületek). Amint megjelennek ARM64-kliensek, láthatóvá válik, mennyi implicit tudás van a rendszerben. És ez pontosan a gazdasági lényeg: a késői igazítások nem csupán „néhány compiler-flag”, hanem olyan feltételezések takarítása, amelyek évek alatt megszilárdultak.

Az ARM64 különösen három helyzetben lesz gyakorlati jelentőségű:

• Hosszú életciklusú kliensszoftver: szakalkalmazások, amelyeket 8–15 éven át használnak és iteratívan bővítenek. Egy új kliensplatform a életciklus közepén valószínűbb, mint egy teljes újraírás.
• Vegyes flották: területi szolgálat/szerviz, menedzsment-notebookok, BYOD-szerű forgatókönyvek vagy leányvállalatok, amelyek más hardvert szereznek be.
• Biztonsági és megfelelőségi nyomás: modern kódfirmázás, keményítés, „least privilege”, kontrollált updater-ek – ezek során a telepítési és frissítési folyamatok amúgy is változnak. Pont ekkor olcsó integrálni az ARM64-et mint mellékfeltételt.

Jó hír: aki amúgy is dolgozik a Delphi Modernizáláson, 64 bites átálláson, az adat-hozzáférések leválasztásán vagy egy szolgáltatorientált célarchitektúrán, az gyakran tudja „magával vinni” Windows 11 ARM64-t – feltéve, hogy az korán a backlogba kerül és nem csak az első ARM-gép beérkezésekor kerül a supporthoz.

Delphi ARM64-en: mi az „könnyű”, mi a „nehéz”?

Delphi-projektek erősen eltérnek: tiszta VCL-desktopkliensektől kezdve többrétegű rendszerekig, amelyekben erőforrások vannak, mint REST-szerver, Windows szolgáltatások, riport-worker-ek, integrációs komponensek és háttérfeladatok. Windows 11 ARM64 szempontjából döntő, hogy mely részeknek kell ténylegesen natívan a kliensen futniuk, és mely részek érdemesek kiszervezni szolgáltatásokba.

A compiler ritkán a fő probléma

Ha a saját kód tiszta (nincs inline-assembler, nincsenek régi 32 bites feltételezések, gyenge pointer-castok, elavult API-hívások), akkor egy új célplatformra történő fordítás gyakran megoldható. A problémát okozzák:

• Harmadik fél komponensek, melyek natív részeket tartalmaznak (DLL-ek, BPL-ek, C/C++ hidak)
• Illesztők és eszközkapcsolat (nyomtatás, szkennelés, aláírópadok, dongle-ok)
• Adatbázis-hozzáférés ODBC/OLE DB/klienstkölcsönökkel, amelyek nem ARM64-kompatibilisek
• Riportálás és Office-integráció (COM-automatizáció, régi exportfilterek)
• Telepítők/Updater-ek, amelyek csak x64-et tesztelnek vagy mereven kódolt utakat használnak

Így Windows 11 ARM64 elsősorban egy „ökoszisztéma-teszt”: mennyire független a szoftvercsomagja a régi platformfeltevésektől?

VCL, FMX és UI-függőségek

Sok B2B-szakalkalmazás VCL-alapú és évek alatt felhalmozódott UI-komponenseket használ. Ez önmagában nem probléma – de a UI gyakran az a hely, ahol a függőségek összpontosulnak: PDF-nyomtatók, vonalkód-generátorok, képkönyvtárak, böngésző-vezérlők, COM-objektumok. ARM64 esetén minél több UI-közeli speciális komponenst használ, annál fontosabb egy korai kompatibilitási lista.

Multiplatform-stratégiáknál (például Windows + macOS) gyakran előkerül az FMX. Keretrendszertől függetlenül robusztus stratégia, hogy leválasszuk a szakmai logikát és integrációkat a UI-ról. Ez mind a Delphi Multiplatform, mind Windows 11 ARM64 szempontjából megtérül.

Tipikus műszaki buktatók (és hogyan ismerhetők fel korán)

Gyakorlatban a legtöbb ARM64-probléma korán felismerhető, ha strukturáltan feltérképez és elvégez egy „ARM64 Readiness” ellenőrzést. Fontos, hogy ne csak a Delphi-kódot vizsgálja, hanem mindent, ami a termékhez tartozik: telepítők, illesztők, konfigurációk, pluginek, harmadik eszközök, frissítési lánc, support-scriptek.

1) Natív DLL-ek, BPL-ek és vegyes processz-landscape-ek

Sok Delphi-alkalmazás további DLL-eket tölt be: kriptográfia, CAD-megjelenítő, OCR, aláírás, hardver-SDK-k, speciális parser-ek. x64-en gyakran automatikus feltételezés, hogy „van 64 bites DLL”. ARM64-nél ez más: kifejezetten ARM64-binárisokra van szükség, vagy egy olyan architektúrára, amely kivonja ezt a függőséget a kliensből.

Gyakorlati megközelítés:

• Készítsen listát az összes betöltött natív modulról (közvetetten komponenseken keresztül is).
• Osztályozza őket: „ARM64 elérhető”, „x64-only”, „32-bit-only”, „ismeretlen”.
• Értékelje, hogy az adott modulnak valóban lokálisan kell-e futnia, vagy kiszervezhető-e szolgáltatásba.

Gyakori megállapítás: egyetlen x64-only modul blokkolhatja az egész ARM64-klienst. Ez az a pont, amikor egy tiszta réteg- vagy Layer-3 architektúra gazdaságilag indokolt: a UI/kliensek könnyűek maradnak, az integrációk kontrollált szerver-/szolgáltatásrétegbe kerülnek.

2) COM, Office-automatizáció és Shell-integrációk

Sok vállalatnál Word/Excel-export, Outlook-integráció, Explorer-kontekstmenük vagy DMS-integrációk COM-on keresztül alakultak ki. A COM nem automatikusan „ARM64-ready”, különösen, ha harmadik fél COM-szerverek vagy bővítmények csak x64-et szállítanak. A 32/64 bites keveredés (Out-of-Proc vs. In-Proc) is gyorsan komplexdé válik.

Korai tisztázás:

• Mely COM-objektumokat használják (ProgID-k/CLSID lista)?
• In-Proc vagy Out-of-Proc? Vannak-e ARM64-regisztrációk?
• Megoldható-e az export szerveroldali könyvtárakkal (például dokumentumalapú formátumok) Office-automatizáció helyett?

Gyakran ez modernizációs kar: elmozdulás a UI-hez kötött automatizációtól reproducálható export-szolgáltatások felé (például PDF/Excel könyvtárakkal), amelyek mind Windows x64, mind ARM64 vagy akár Linux-szerverek esetén alkalmazhatók.

3) Adatbázis-hozzáférés: ODBC, klienskönyvtárak, régi BDE

Az adat-hozzáférés gyakori ARM64-kikötő, mert itt az illesztő- és klienskönyvtárak számítanak. Különösen kritikusak a régi ODBC-beállítások, a proprietáris adatbázis-kliensszoftverek vagy helyi adatbázisok történelmi hozzáférési rétegei.

Delphi-stackeknél ez klasszikus probléma: ha még Borland BDE, régi Paradox-struktúrák vagy nehezen karbantartható illesztőláncok vannak használatban, az ARM64 katalizátorrá válik. Egy BDE-kiváltás és a váltás egy BDE-kiváltásra natív csatlakozással és egy világos DB-illesztő stratégiával jelentősen csökkenti a platformkockázatokat.

Konkrét ellenőrzőpontok:

• Milyen DB-k vannak használatban (SQL Server, PostgreSQL, MariaDB, Firebird, helyi motorok)?
• Milyen illesztők vannak használatban (ODBC, natív kliens, BDE-Ablosung mit nativer Anbindung-illesztő, OLE DB)?
• Hol találhatók a connection stringek és DSN-ek (felhasználónként, gépenként, telepítőben)?
• Vannak-e függőségek 32 bites ODBC-illesztőkre vagy régi providerekre?

Különösen SQL Server/ODBC esetén egy ARM64-kliens működhet – de csak akkor, ha az illesztőlánc és a telepítési rutin tiszta. Ez nem az a probléma, amit „a helyszínen“ szeretne debugolni.

4) Riportálás, nyomtatás, szkennelés, PDF és output-workflow-k

Az output a szakalkalmazásoknál gyakran üzletileg kritikus: fuvarlevél, címkék, számlák, jegyzőkönyvek, mérőállás, igazolások, szállítási címkék. Sok ilyen folyamat riportkomponensekre vagy specifikus nyomtató-/szkennertrevíziókra épül.

Windows 11 ARM64-n a tipikus buktatók:

• Címkenyomtató-/speciális illesztők csak x64-ként elérhetők
• Szkenner-szoftver/SDK-k ARM64-támogatás nélkül
• Régi riportmotorok natív preview-/export-modulokkal
• PDF-generálás „virtuális nyomtatókkal” könyvtár helyett

Egy robusztus megközelítés az output-workflow-k szabványosítása: PDF/Office-formátumok könyvtárakon keresztül előállítása, nyomtatás standardizált interfészeken keresztül, speciális hardverhozzáférések kapszulázása. Ahol ez nem lehetséges, korán szükség van egy eszköz-/illesztő-mátrixra ARM64-re.

5) Telepítők, updater-ek, kódfirmázás és üzemeltetés

Sok ARM64-projekt nem a programon bukik el, hanem a kiszállításon: a setup rosszul ismeri fel az architektúrát, nem telepíti az illesztőket, nem regisztrálja a COM-ot, hibás utakat állít be vagy a kódfirmázási szabályokba ütközik. Az automatikus frissítések (delta-update-ek, self-updater) is gyakran erősen architektúrafüggők.

Fontos üzemeltetési kérdések:

• Hogyan történik a telepítés (MSI, Inno Setup, saját updater)?
• Hogyan települnek a függőségek (VC++ runtimes, illesztők, tanúsítványok)?
• Hogyan történik a firmázás (EXE, DLL, telepítő, illesztőcsomagok)?
• Hogyan tesztelik: valódi ARM64-hardveren vagy csak feltételezéseken?

Vállalati szinten ez kormányzási kérdés: ha Windows 11 ARM64 megjelenik a kliensflottában, a deploymentnek reprodukálhatónak kell lennie – visszagörgetés, supportképesség és egyértelmű verziózás mellett.

Stratégia: Windows 11 ARM64 mint „korai nem-funkcionális követelmény”

A gazdaságilag ésszerű megközelítés az, hogy az ARM64-et úgy kezeljük, mint egy nem-funkcionális követelményt (NFA) – hasonlóan a teljesítményhez, biztonsághoz vagy offline-képességhez. Ez azt jelenti: nem az első égő probléma esetén egy sprintben, hanem mint meghatározott irányelvet az architektúra és a beszállítási lánc számára.

ARM64-Readiness-Check: leltár érzés helyett

Egy terhelhető ellenőrzés tipikusan magában foglalja:

• Függőségleltár: minden harmadik fél komponens, DLL, illesztő, SDK, böngésző-vezérlő, kriptomódul, riportálás.
• Build-/pipeline-elemzés: build-targetok, csomagolás, firmázás, artefakt-tárolás, verziószámozás, reprodukálhatóság.
• Telepítő-/frissítési lánc: setup-logika, prerequisit-ek, Registry/fájlrendszer-útvonalak, policy-k, jogosultságok.
• Üzemmodell: support, logging, crash-dumpok, telemetria (ha van), rollout-terv.

Az eredmény nem „ARM64: igen/nem” legyen, hanem egy priorizált lista: mely blokkolók léteznek, mely modulok érintettek, milyen alternatívák állnak rendelkezésre és milyen befektetés reális.

Döntési mátrix: natív ARM64 vagy leválasztás?

Minden problémás függőségnél érdemes egyértelmű döntést hozni:

• ARM64-natív helyettesítés lehetséges: frissítés, beszállítócsere, váltás másik könyvtárra.
• A függőség kiszervezhető: például egy Windows szolgáltatásba, egy háttérworker-be vagy egy központi REST-szerverbe.
• A függőségnek lokálisan kell maradnia: például mert a hardver közvetlenül a klienshez csatlakozik. Ebben az esetben kötelező ARM64-hardver-/illesztőjóváhagyások szükségesek.

Integrációk esetén a kiszervezés gyakran a legegyszerűbb megoldás: a kliens marad UI + üzleti dialógusokkal, míg a komplex integrációs logika kontrollált szolgáltatásokba kerül. Ez az ARM64 mellett támogatja a központi frissítéseket, jogosultsági koncepciókat és jobb tesztelhetőséget.

Architektúra-pattern-ek, amelyek stabilabbá teszik az ARM64-projekteket

Ha Windows 11 ARM64-t korán beépítik, több architektúra-döntés meghozatala lehetővé teszi, hogy később ne kelljen drágán visszavonni azokat.

1) Tiszta rétegek: UI, üzleti logika, integráció, adat-hozzáférés

A felhalmozódott Delphi-kliensek gyakran „mindent egy folyamatban“ tartalmaznak: UI, üzleti szabályok, adat-hozzáférés, DMS-integráció, nyomtatás és export. Ez karbantartható, amíg a platform stabil marad. Ha azonban platformváltozatok (ARM64, esetleg macOS, esetleg terminálszerver) relevánssá válnak, nő a tiszta rétegzési elv értéke.

Pragmatikus célkép:

• UI-réteg: minimális, tesztelhető, nincs közvetlen illesztő-/SDK-függőség.
• Üzleti logika: lehetőleg platformsemleges, jól modellezett.
• Integrációs réteg: kapszulázza a COM-ot, fájlformátumokat, DMS/ERP-connectorokat, eszköz-SDK-kat.
• Adat-hozzáférés: konszolidált (például FireDAC), világos tranzakciós határok, nincs szétszórt SQL.

Ez nem „akadémia“, hanem valódi költségmegtakarítás: ha csak az integrációs réteg ARM64-problémás, nem kell az egész klienst újraírni.

2) Szolgáltatások és REST-szerverek mint stabilitási horgonypontok

Sok B2B-rendszer hasznát veszi annak, ha központi funkciókat REST-szerverként vagy Windows-/Linux-service-ként futtatnak: jogosultságellenőrzés, dokumentum-workflow-k, adatvalidáció, export, import, ERP/DMS/CRM interfészek. Ha ezek szerveroldalon futnak, a kliens komplexitása jelentősen csökken – és ez redukálja az ARM64-ra eső kitettséget.

Tipikus felosztások, amelyek beváltak:

• Kliens: dialógusok, megjelenítés, offline-logika (szükség esetén), minimális lokális integrációk.
• REST-szerver: szakmai műveletek, validáció, többbérlőségtámogatás, központi naplózás.
• Worker/Service: időzített feladatok, interfész-polling, riportgenerálás, batch-exportok.

Ez illeszkedik a modern üzemeltetési modellekhez: egy szerveroldalon futó funkció egyszer frissül – nem kell minden ARM64-klienst külön frissíteni.

3) Egy build-rendszer, több target (x64 + ARM64) már az elejétől

Ha az ARM64 cél, a build-pipeline-nak tükröznie kell ezt. Nem úgy, hogy „majd később készítünk egy külön buildet“, hanem standardként: minden release-kandidát verzió reprodukálhatóan épüljön x64-re (és ha tervezett, ARM64-re is), firmázással és telepítő-csomagolással együtt.

Fontosabb a következetesség, mint az eszközkészlet:

• Artefaktumok egyértelmű elnevezése (architektúra a csomagnévben/mappaszerkezetben).
• Konfigurációs értékek targetenkénti szétválasztása (útvonalak, prerequisit-ek, illesztőcsomagok).
• Smoke-tesztek minden architektúrára definiálva (indítás, login, DB-kapcsolat, nyomtatás/PDF).

Így az ARM64 nem lesz „Big Bang”, hanem egy kontrollált, további target.

Delphi-modernizáció: ARM64 alkalom a műszaki adósság célzott leépítésére

Számos vállalat az új platformkövetelményt „minden újjáépítésére” használja. Ez kockázatos és gyakran fölösleges. Gazdaságosabb, ha Windows 11 ARM64-t irányelvnek tekintik a lépcsőzetes modernizációhoz: a műszaki adósságot ott szüntetik meg, ahol az ARM64 blokkol vagy a szállíthatóságot veszélyezteti.

64-bit és Unicode: régi problémákat ne húzzunk tovább

Ha a kódbázisban még 32 bites feltételezések vagy korai Delphi-verziók terhei vannak, ezek platformváltáskor ismét előjönnek. Bár ARM64 nem automatikusan jelenti a „Unicode” bevezetését, sok projekt, amely komolyan foglalkozik ARM64-gyel, egyidejűleg biztosítja, hogy a Unicode rendezett legyen, a 64-bites utak etablálva legyenek és a memória-/pointer-problémák tisztázva legyenek.

A cél nem a tökéletesség, hanem egy megbízható normagyűjtemény: olyan kód, amely az új targetekre építhető anélkül, hogy újra és újra ugyanazokat a hibakategóriákat produkálná.

BDE-kiváltás és konszolidált adat-hozzáférés mint ARM64-enkóder

Ahol még történelmi hozzáférési rétegek vannak (BDE, helyi Paradox-adatok, vegyes adat-hozzáférések), ott a konszolidáció többszörös hatású emelő: könnyebben karbantartható kód, stabilabb deployok, világosabb illesztő-stratégia. FireDAC segítségével sok forgatókönyvben egységesíthető a hozzáférés, beleértve a központi paraméterkezelést, pooling-stratégiát és tiszta hibakezelést.

Fontos: egy BDE-kiváltás nem csupán „komponenscserét” jelent. Hatással van tranzakciós logikára, adattípusokra, rendezésekre, szűrősemantikára és részben az adatmodellre is. Ezért tervezetten kell végrehajtani – nem vészmegoldásként, mikor az ARM64-kliensek hirtelen megjelennek a gyakorlatban.

Teszt és minőségbiztosítás: ARM64 csak akkor tervezhető, ha mérhető

ARM64 korai beépítése azt is jelenti: tesztelni kell – nem minden funkció teljes körű tesztelését egyszerre, hanem célzott kockázatesztelést a kritikus láncon. A legfontosabb lépés egy valódi ARM64-tesztrendszer rendelkezésre állása. Az emuláció egyes esetekben segíthet, de nem helyettesíti a valódi hardverrel, valódi illesztőkkel és valódi biztonsági szabályokkal végzett gyakorlatot.

Minimális ARM64-smoke-test: mi legyen korán lefedve

Egy pragmatikus, de hatásos smoke-tesztkészlet minden release-kandidát verzióhoz:

• Program indítása, bejelentkezés, alapvető UI-funkciók
• DB-kapcsolat (beleértve hitelesítést, tanúsítványokat, DNS/Proxy beállításokat, ha releváns)
• Egy kulcsfolyamat „end-to-end” (például megrendelés létrehozása, mentése, nyomtatása/exportja)
• Updater/Installer: tiszta telepítés és verziók közötti frissítés
• Logging/hibadiagnosztika: értelmezhetők-e a diagnózisok ARM64-en is?

Így a tipikus ARM64-blokkolók korán láthatóvá válnak: hiányzó DLL-ek, hibás illesztők, setup-problémák, váratlan jogosultságigények.

Diagnosztikai képesség: crash-dumpok, logok, verziótranszparencia

Ha ARM64 megjelenik a flottában, support-esetek érkeznek – már csak az új illesztőkonstellációk miatt is. Érdemes standardizálni a diagnózist: egyértelmű build-ID-k, informatív logok, reprodukálható telepítési és frissítési útvonalak. Ez nem kizárólag ARM64-specifikus, de ARM64 felgyorsítja, hogy ezek hiánya gyorsan költségessé váljon.

Rollout és üzemeltetés: vegyes flották káosz nélkül

A legtöbb vállalat középtávon vegyes kliensflottát fog üzemeltetni: részben x64, részben ARM64. A kulcs az, hogy ezt az állapotot tudatosan alakítsák.

Csomagolás: külön telepítők, egyértelmű felismerés, tiszta letöltési utak

Gyakorlatban legjobban akkor működik, ha a telepítők/csomagok egyértelműek: az x64-csomag x64, az ARM64-csomag ARM64. Az „egy telepítő mindenre” kényelmesnek hangzik, de gyorsan bonyolulttá válik (ellenőrzés, prerequisit-ek, illesztőutak, firmázás, javítótelepítés). Kontrollált vállalati rolloutoknál az egyértelműség gyakran robusztusabb út.

Frissítési stratégia: nincs külön út ARM64-nek

ARM64-nek nem szabad külön esettel lenni a frissítési folyamatban. A cél: azonos release-gyakoriság, azonos szakverziószám, de külön artefaktumok. Ha ARM64 csak „kézzel” frissül, flottaeltérések keletkeznek, amelyek később megdrágítják a supportot.

Integrációk gondos dokumentálása

Sok ARM64-probléma nem a saját kódból fakad, hanem az integrációkból: ERP-connector, DMS-kliensek, aláírási szolgáltatások, szkenner-szoftverek, címkenyomtatók. Egy naprakész integrációs lista verziókkal és architektúra-megjegyzésekkel B2B-rendszerekben eleve hasznos – és transzparenssé teszi az ARM64-döntéseket.

Mit tegyenek a vállalatok most konkrétan (akcióizmus nélkül)

Windows 11 ARM64 korai tervezése nem jelenti azt, hogy mindent azonnal át kell építeni. A cél, hogy a megfelelő kérdéseket időben megválaszolják és a blokkolókat megszüntessék, amíg a ráfordítás tervezhető. Egy bevált eljárás:

• 1) Feltárás (2–10 nap a rendszer méretétől függően): függőségek, telepítők, illesztők, adat-hozzáférés, COM, riportálás.
• 2) Célkép és út: mi kell natívan a kliensre? Mi lesz szolgáltatás/REST? Mely komponensek cserélődnek?
• 3) Proof of Feasibility: egy futtatható ARM64-build telepítővel és egy end-to-end use-case-szel.
• 4) Lépésenkénti megerősítés: fennmaradó funkciók, tesztek, frissítési lánc, diagnosztikai képességek.

Így nem keletkezik egy „ARM64-projekt”, amely hónapokig elszigetelten fut, hanem a szállíthatóság kontrollált kibővítése.

Következtetés: Windows 11 ARM64 nem divathullám, hanem korai indikátor a műszaki érettségre

Windows 11 ARM64 sok vállalatnál egyszerűen valósággá válik – hardverbeszerzés, mobilitási igények vagy standardizáció miatt. Delphi-alkalmazásoknál a valódi kihívás nem csupán a forráskód, hanem az egész rendszer: függőségek, telepítési és frissítési folyamatok, integrációk és illesztők. Aki ARM64-et korán beépít a tervezésbe, strukturáltan tisztázhatja ezeket a pontokat, ahelyett, hogy később időnyomás alatt „patch-elné” őket.

Végső soron az ARM64 hasznos vizsgakő: mennyire laza az alkalmazása, mennyire tesztelhető és szállítható? Ha most megválaszolja ezt a kérdést, nem csak további platformopciókat nyer, hanem stabilabb alapot a modernizációhoz, szolgáltatásokhoz, REST-architektúrákhoz és a hosszú távú karbantarthatósághoz.

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.