Планирајте Windows 11 ARM64 рано за Delphi-апликације

Windows 11 ARM64 више није само slučaj za технолошке ентузијасте у B2B-свакодневици. Нове генерације ноутбука, дужи век батерија, „Always-on“ сценарији и растућа потражња за лаким, мобилним радним местима доводе до тога да компаније купују ARM64 клијенте – понекад свесно, понекад успут преко стандардних модела у оквиру рамног уговора. За тимове са развијеним индивидуалним софтвером то је јасна порука: ARM64 мора рано у техничко планирање, иначе ће касније постати скуп пројекат накнадних измена.

Код Delphi-апликација централно питање ретко гласи „може ли Delphi да компајлира?“. У пракси ARM64 rollout-и готово увек заостају на периферији: на нативним DLL-овима, компонентама за штампу/скенирање, драйверима за базе података, report-енџинима, COM-интеграцијама, setup-рутинама, code-signing-у или build-pipeline-има који ћутке познају само x64. Баш због тога вреди третирати Windows 11 ARM64 као архитектонски и оперативни захтев – а не као чисто платформску функцију.

Овај чланак показује који технички проблеми типично настају код Delphi-а, како систематски идентификовати ризике и који прагматични миграциони путеви су се показали корисним – од постепене припреме појединих модула до јасне циљне архитектуре са сервисима и REST-серверима.

Зашто је Windows 11 ARM64 сада архитектонска тема

У многим компанијама „Windows“ је дуго значило x86/x64. Ово претпостављање је уграђено у скрипте, инсталере, third-party компоненте и понекад чак и у модел података (напр. путanje, registry-ключеви, интерфејси драјвера). Како се појављују ARM64 клијенти, види се колико имплицитног знања систем садржи. И управо ту лежи економска поента: касне прилагоде нису само „неколико флагова компајлера“, већ средивање претпоставки које су се годинума стваралe.

ARM64 постаје практично релевантан нарочито у три ситуације:

• Клијент-сoфтвер са дугим животним веком: стручне апликације које се користе 8–15 година и итеративно проширују. Нова клиент-платформа усред животног циклуса је вероватнија од потпуног реинжењеринга.
• Мешовите флоте: теренски/сервисни тимови, менаџерски ноутбоци, сценарији блиски BYOD-у или дочерње фирме које набављају другу хардверску опрему.
• Притисак на безбедност и усаглашеност: модерно code-signing, hardening, „least privilege“, контролисани updater-и – при томе се инсталциони и update процеси иначе мењају. Тада је повољно интегрисати ARM64 као спорадичан захтев.

Добра вест: ко већ ради на Delphi Modernisierung, преласку на 64-бита, раздвајању приступа подацима или на service-oriented циљну архитектуру, често може „повући“ и Windows 11 ARM64 – под условом да се та тема рангира у backlog-у, а не да се појави тек код прве ARM машине у подршци.

Delphi на ARM64: шта је „лакo“, шта је „тешко“?

Delphi-пројекти се значајно разликују: од чистих VCL desktop клијената до вишеслојних система са REST-серверима, Windows сервисима, report-воркерима, интеграционим компонентама и background job-овима. За Windows 11 ARM64 је пресудно које делове заиста морају да раде нативно на клијенту и које делове је у сваком случају практичније изместити у сервисе.

Компajлер ретко представља главни проблем

Ако је сопствени код чист (без inline-асемблера, без старих 32-битних претпоставки, без крхких pointer-cast-ова, без застарелих API позива), компајлирање за нову таргет-платформу је често изводљиво. Проблеми настају услед:

• Third-Party компоненти са нативним деловима (DLL-ови, BPL-ови, C/C++ мостови)
• Драјвери и повезивање уређаја (штампа, скен, signature-pads, dongle-ови)
• Приступ бази података преко ODBC/OLE DB/Client-Libraries који нису ARM64-способни
• Репортинг и Office-интеграција (COM-automation, стари export-филтери)
• Инсталер/Updater који тестирају само x64 или користе тврдокодиране путеве

Стога је Windows 11 ARM64 пре свега „екосистем-тест“: колико је ваш софтверски пакет декоплован од старих платформских претпоставки?

VCL, FMX и UI-зависности

Многа B2B стручна решења су базирана на VCL-у и користе UI-компоненте које су се годинама развијале. То само по себи није проблем – али UI је често место где се зависности акумулирају: PDF штампачи, barcode-генератори, библиотеке за слике, browser-контроли, COM-објекти. За ARM64 важи правило: што више UI-близих специјалних компоненти користите, то је важнији рани popis компатибилности.

Код мултиплатформских стратегија (нпр. Windows + macOS) често се укључује FMX. Независно од фрејмворка, робусна стратегија је одвојити стручну логику и интеграције од UI-ја. То користи и Delphi Multiplattform и Windows 11 ARM64.

Типичне техничке замке (и како их рано уочити)

У пракси се већина ARM64-проблема може рано открити ако систематски направите инвентар и изведете „ARM64 Readiness“ чек. Кључно је не гледати само Delphi-код, већ све што припада производу: инсталере, драјвере, конфигурацију, плагине, алате трећих страна, update-ланце, support-скрипте.

1) Нативни DLL-ови, BPL-ови и мешовити процеси

Многа Delphi-решења учитавају додатне DLL-ове: криптографију, CAD-viewer, OCR, потпис, hardware-SDK-ове, специјалне парсере. На x64 се често подразумева да „постоји 64-бит DLL“. За ARM64 је другачије: нужно су вам експлицитно ARM64 бинарни фајлови или архитектура која ову зависност уклања са клијента.

Практични приступ:

• Направите листу свих учитаних нативних модула (укључујући индиректне преко компонената).
• Класификујте: „ARM64 доступно“, „x64-only“, „32-bit-only“, „нејасно“.
• Оцeните да ли модул заиста мора бити локалан или може бити измештен као сервис.

Чест налаз је: један x64-only модул блокира целокупни ARM64 клијент. То је тренутак када чиста слојна или Layer-3 Архитектура постаје економична: UI/клијент остаје лаган, интеграције се премештају у контролисане сервер/сервис слојеве.

2) COM, Office-Automation и Shell-интеграције

У многим компанијама Word/Excel-експорт, интеграција са Outlook-ом, context-мену у Explorer-у или DMS-интеграције настале су историјски преко COM-а. COM није аутоматски „ARM64-ready“, посебно ако COM-сервери или add-in-ови трећих страна испоручују само x64 верзије. И рад 32-бит/64-бит мешавина (out-of-proc vs. in-proc) брзо може постати сложен.

Рана разјашњења:

• Који COM-објекти се користе (ProgIDs/CLSID листа)?
• In-Proc или Out-of-Proc? Постоје лиARM64 регистрације?
• Може ли се експорт решити преко серверских библиотека (напр. документ-оријентисани формати) уместо Office-Automation?

Често је ово полуга модернизације: удаљити UI-повезану аутоматизацију и прећи на репродуцираме export-сервисе (нпр. PDF/Excel преко библиотеке) који су употребљиви како за Windows x64 тако и за ARM64 или чак Linux-сервере.

3) Приступ бази података: ODBC, Client-Libraries, Legacy-BDE

Приступ подацима је чест ARM64-ниво јер ту улазе драјвери и client-library екосистеми. Посебно критични су стари ODBC-ски сетапи, пропријетарни клијенти база или локалне базе са историјским слојевима приступа.

За Delphi-стек то је класика: ако и даље постоји Borland BDE, старе Paradox структуре или тешко одржаваљиви ланац драјвера, ARM64 постаје катализатор. BDE-Ablösung и прелаз на BDE-Ablösung mit nativer Anbindung са јасном DB-драјвер стратегијом значајно смањују платформске ризике.

Конкретне проверне тачке:

• Које базе су у употреби (SQL Server, PostgreSQL, MariaDB, Firebird, локални енджини)?
• Које драјвере користите (ODBC, native Client, BDE-Ablosung mit nativer Anbindung-драјвер, OLE DB)?
• Где су connection-string-ови и DSN-ови смештени (по кориснику, по машини, у инсталеру)?
• Постоје ли зависности од 32-бит ODBC-драјвера или старих провајдера?

Посебно код SQL Server/ODBC, ARM64 клијент може функционисати – али само ако је низ драјвера и инсталациона рутина чиста. Није то нешто што желите „да дебагујете на терену“.

4) Репортинг, штампа, скен, PDF и output-воркфлови

Output у стручним апликацијама често је пословно критичан: отпремнице, етикете, рачуни, извештаји, очитавања бројила, сертификати, штанпање налепница. Много тих радних токова зависи од report-компоненти или специфичних штампач/скен драјвера.

На Windows 11 ARM64 су типичне замке:

• Драјвери за етикетне штампаче/специјални драјвери доступни само као x64
• Скен софтвер/SDK без ARM64 подршке
• Стари report-енџини са нативним preview/export модулима
• Генерисање PDF-а преко „виртуелних штампача“ уместо библиотеке

Робустан приступ је стандардизовати output-воркфлове: генерисати PDF/Office формате преко библиотека, штампу водити преко стандардизованих интерфејса, специјалан приступ хардверу у што већој мери капсулирати. Тамо где то није могуће, потребна је рана матрица уређаја/драјвера за ARM64.

5) Инсталер, Updater, Code-Signing и оперативни рад

Многи ARM64-пројекти не пропадну због програма, већ због испоруке: setup погрешно препозна архитектуру, не инсталира драјвере, не региструје COM, постави погрешне путеве или заломи на code-signing политике. Аутоматски update-и (delta-упдејти, self-updater-и) такође су често јако зависни од архитектуре.

Важно за оперативу:

• Како се инсталира (MSI, Inno Setup, сопствени Updater)?
• Како се инсталирају зависности (VC++ Runtimes, драйвери, сертификати)?
• Како се врши sign-овање (EXE, DLL, инсталер, пакет драјвера)?
• Како се тестира: права ARM64 хардверска опрема или само претпоставке?

За компанију је ово питање управљања: ако се Windows 11 ARM64 појави у клијент-флоти, deployment мора бити репродуцирабилан – укључујући rollback, подржљивост и јасну верзионисање.

Стратегија: Windows 11 ARM64 као „рана нефункционална захтевност“

Економски смислен приступ је третирати ARM64 као нефункционални захтев (NFA) – слично као перформансе, сигурност или offline-функционалност. То значи: не чекати до sprint-а „када изненада затреба“, већ га дефинисати као смерницу за архитектуру и ланце снабдевања.

ARM64-Readiness-Check: инвентар уместо осећаја

Поуздан чек типично обухвата:

• Инвентар зависности: све third-party компоненте, DLL-ове, драйвере, SDK-ове, browser-Controls, криптомодуле, репортинг.
• Анализа build-/pipeline-а: build-targets, пакетирање, sign-овање, складиштење артефаката, нумерација верзија, репродуцибилност.
• Капија инсталера/апдејта: setup-логика, prerequisite-ови, registry/фајлсистем путеви, политике, привилегије.
• Оперативни модел: подршка, логовање, crash-dump-ови, телеметрија (ако постоји), план rollout-а.

Резултат не би требао бити „ARM64: да/не“, већ приоритетна листа: који блокери постоје, који модули су погођени, које алтернативе постоје и која је реалистична инвестиција.

Матрица одлука: нативно на ARM64 или декоплатирати?

За сваку проблематичну зависност вреди јасна одлука:

• ARM64-нативна замена могућа: upgrade, промена произвођача, прелаз на другу библиотеку.
• Зависност се може изместити: нпр. у Windows сервис, background worker или централни REST-сервер.
• Зависност мора остати локална: нпр. јер је хардвер директно прикључен на клијент. Тада су потребна обавезна ARM64-hardware/драјвер дозвола.

За интеграције је често најчистије решење измештање: клијент остаје UI + стручни дијалози, док комплексна интеграциона логика ради у контролисаним сервисима. То поред ARM64 подржава и централизована ажурирања, концепте права и бољу тестабилност.

Архитектонски патерни који чине ARM64 пројекте стабилним

Када се Windows 11 ARM64 планира рано, може се донети неколико архитектонских одлука тако да касније не буду скупе за ревизију.

1) Јасни слојеви: UI, стручна логика, интеграција, приступ подацима

Разрасли Delphi-клијенти често имају „све у једном процесу“: UI, бизнис-правила, приступ подацима, DMS-везе, штампу и експорт. То је одрживо док платформа остаје стабилна. Али када се појаве варијанте платформи (ARM64, ев. macOS, ев. терминалски сервери), вредност јасног слојева расте.

Прагматичан циљ:

• UI-слој: минималан, тестабилан, без директних драйвер/SDK-зависности.
• Стручна логика: колико је могуће платформно неутрална, чисто моделована.
• Интеграциони слој: капсулира COM, формате датотека, DMS/ERP-канекторе, device-SDK-ове.
• Приступ подацима: консолидован (нпр. FireDAC), са јасним транзакционим границама, без разбацаних SQL-фрагмената.

То није „академски“, већ штеди реалне трошкове: ако је само интеграциони слој ARM64-проблематичан, не мора се читав клијент преправљати.

2) Сервисни слој и REST-сервери као ослонац стабилности

Многа B2B-решења имају користи од тога да кључне функције раде као REST-сервер или као Windows-/Linux-сервиси: проверa права, документни радни токови, валидaција података, експорт/импорт, интерфејси ка ERP/DMS/CRM. Када ове функције раде серверски, сложеност на клијенту значајно опада – и тиме се смањује и ARM64 нападна површина.

Типичне поделe које се показале корисним:

• Клијент: дијалози, приказ, offline-логика (ако је потребна), минималне локалне интеграције.
• REST-сервер: стручне операције, валідација, мулти-тенант подршка, централна евиденција.
• Worker/Service: периодични задаци, polling интерфејса, генерисање извештаја, batch-експорти.

То одговара и модерним оперативним моделима: функција која ради серверски се ажурира једном – уместо на сваком ARM64 клијенту појединачно.

3) Један build-system, више таргета (x64 + ARM64) од почетка

Ако је ARM64 циљ, build-pipeline треба да то одражава. Не као „урадићемо посебан build касније“, већ као стандард: свака release-кандидат верзија се репродуцибилно гради за x64 (и, ако је предвиђено, ARM64), укључујући sign-овање и пакетирање инсталера.

Важнија је конзистентност него алати:

• Артефакте јасно именовати (арxитектура у имену пакета/фолдеру).
• Одвојити конфигурационе вредности по таргету (путеви, prerequisite-ови, пакет драјвера).
• Дефинисати smoke-тестове по архитектури (покретање, логин, DB-веза, штампа/PDF).

Тако ARM64 не постаје „Big Bang“, већ контролисани додатни таргет.

Delphi-модернизација: ARM64 као прилика за редукцију техничког дуга

Многе компаније користе нове платформске захтеве као повод за „све од почетка“. То је ризично и често непотребно. Економичније је користити Windows 11 ARM64 као смерницу за постепену модернизацију: отклањати технички дуг тамо где он блокира ARM64 или угрожава испоруку.

64-бит и Unicode: не заташкавати старе проблеме

Ако код база и даље садржи 32-битне претпоставке или наслеђе из раних Delphi верзија, то ће се појавити при промени платформе. Иако ARM64 не значи аутоматски „Unicode“, многи пројекти који озбиљно приступају ARM64-у у истој фази обезбеђују исправну Unicode подршку, успостављање 64-бит стаза и чишћење памћењских/пойнтер питања.

Циљ није перфекција, већ поуздан стандард: код који се може градити за нове таргете без понављања истих класа грешака.

BDE-Ablösung и консолидација приступа подацима као ARM64-енаблер

Где још постоје историјски слојеви приступа ( BDE, локални Paradox-подaци, мешовити приступи), консолидација је полуга са више ефеката: лакше одржавање, стабилнији deployments, јаснија драјвер-стратегија. Са FireDAC приступ се у многим сценаријима може уједначити, укључујући централизовано управљање параметрима, pool-инг стратегије и чисто руковање грешкама.

Важно: BDE-Ablösung није само „замена компоненти“. Она утиче на транзакциону логику, типове података, сортирања, семантику филтера и делом и на модел података. Због тога треба да буде планирана – а не као мера у ванредним околностима када се ARM64 клијенти изненада појаве у терену.

Тест и контролa квалитета: ARM64 се може планирати само ако је мерљив

Рано планирање ARM64 такође значи: мора се тестирати – не пуном провером сваке функције, већ циљаним тестирањем критичних ланаца ризика. Најважнији корак је реално ARM64 тест окружење. Емуляција у појединачним случајевима може помоћи, али не замењује рад на стварној хардвери, са стварним драјверима и стварним безбедносним политикама.

Минимални ARM64-smoke тест: шта би рано требало покрити

Прагматичан, али ефикасан сет smoke-тестова за сваку release-кандидат верзију:

• Покретање програма, логин, основне UI-функције
• DB-веза (укључујући аутентификацију, сертификате, DNS/Proxy ако је релевантно)
• Један кључни процес „end-to-end“ (нпр. креирање наруџбине, чување, штампа/експорт)
• Updater/Installer: нова инсталација и апдејт преко верзије
• Логовање/дијалози о грешкама: да ли су дијагнозе на ARM64 корисне?

Тако рано бивају видљиви типични ARM64-блокери: недостајуће DLL-ове, погрешни драјвери, проблеми са setup-ом, неочекивани захтеви права.

Дијагностичка способност: crash-dump-ови, логови, јасност верзија

Кад ARM64 уђе у флоту, случајеви подршке ће стизати – због нових комбинација драјвера. Због тога вреди стандартизовати дијагнозу: јасне build-ID-e, смислени логови, репродуцирабилни инсталациони и update-путање. То није специфично само за ARM64, али ARM64 чини недостатке овде брзо скупим.

Rollout и операција: мешовите флоте без хаоса

Већина компанија ће средњорочно имати мешовите клијент-флоте: део x64, део ARM64. Кључ је свесно управљање тим стањем.

Пакетирање: одвојени инсталери, јасно препознавање, једнозначни download-канали

У пракси најбоље функционише ако су инсталери/пакети јасно означени: x64-пакет је x64, ARM64-пакет је ARM64. „Један инсталер за све“ звучи згодно, али брзо постаје сложено (логика провера, prerequisite-ови, путање драјвера, sign-овање, repair-инсталација). За контролисане корпоративне rollout-ове јасноћа је често робуснији приступ.

Стратегија ажурирања: нема посебних путева за ARM64

ARM64 не би требало да буде посебан случај у процесу ажурирања. Циљ је: иста фреквенција издања, иста бројевна верзија функционалности, али одвојени артефакти. Ако се ARM64 ажурира „ручно“, настају разлике у флоти које ће касније повећати трошкове подршке.

Интеграције – детаљна документација

Многи ARM64-проблеми нису у сопственом коду већ у интеграцијама: ERP-канектор, DMS-клијент, сервис за потпис, скенер софтвер, етикетни штампач. Одржавана листа интеграција са верзијама и архитектонским белешкама је за B2B системе корисна – и чини ARM64-одлуке транспарентним.

Шта компаније сада конкретно треба да ураде (без акционизма)

Рано планирање Windows 11 ARM64 не значи одмах све преуређивати. Значи рано поставити права питања и елиминисати блокере док је напор плански. Препоручен процес је:

• 1) Преглед стања (2–10 дана у зависности од величине система): зависности, инсталери, драјвери, приступ подацима, COM, репортинг.
• 2) Циљно стање и пут: шта мора нативно на клијенту? шта иде у сервис/REST? које компоненте се замењују?
• 3) Proof of Feasibility: радни ARM64-build са инсталером и једним end-to-end use-case-ом.
• 4) Постепено ојачавање: преостале функције, тестови, update-ланци, дијагностичка способност.

Тако не настаје „ARM64-пројекат“ који месецима ради изоловано, већ контролисано ширење испоручивости.

Закључак: Windows 11 ARM64 није хипе, већ рани индикатор техничке зрелости

Windows 11 ARM64 ће за многе компаније постати једноставно реалност – кроз набавку хардвера, захтеве за мобилност или стандардизацију. За Delphi-апликације прави изазов није само изворни код, већ цео систем зависности, инсталационих и update-процеса, интеграција и драјвера. Ко рано планира ARM64, може те теме систематски рашчланити, уместо да их касније „патчи“ под притиском.

На крају, ARM64 је користан прoверник: колико је ваша апликација декоплирана, тестабилна и испоручива? Ако то питање сада решите, не добијате само додатне опције платформе, већ и стабилнију основу за модернизацију, сервисе, REST-архитектуре и дугорочно одржавање.

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.