ANT — це Операційна Система (далі ОС), яку я пишу як особистий проєкт, з цікавости, як справу для душі. Вона натхненна сімейством ОС Microsoft Windows NT, але не є її клоном, шо строго слідує оригіналу, не кажучи вже за бінарну сумісність — це було б просто нездійсненно для проєкту однієї особи, та це й не зовсім те, шо прагнеться. Як сказано вище, це творчий проєкт і бажання створити шось схоже на NT і WinAPI було наслідком вподобання цієї ОС та її API, а не бажанням "змагатися", "боротися", "замінити" чи шось подібне, шо йде з словника тих, хто баче в розробці ПЗ "ідеологію і політику" (або, скоріше, — релігію).
ANT — це модулярне ядро, з модулями (драйверами) для управління периферійними пристроями або надавання розширеної функціональности або абстраґування і вони (зазвичай) бігатимуть в режимі ядра. Виконувані образи суть в форматі Portable Executable (PE), для обох режимів — ядра й користувача. Цей формат мені подобається на відміну від ELF, підтримка якого розглядається лише як план, для архітектур, на яких нема компіляторів, шо можуть ґенерувати PE образи (а точніше, — генератори коду яких не розуміють __declspec(dllimport) для цих архітектур).
Вона є многокористувацькою ОС загального призначення для настільних, подібних до настільних, серверних, мобільних та, можливо, інших сценаріїв. Многопотокова, з преемптивною (виштовхувальною) диспетчеризацією потоків. Має підтримувати Симетричну та Гетерогенну Многопроцесорність (загільновідомі абревіатури — SMP та HMP відповідно).
Конфігурація компонентів ОС і програм зберігається в Реєстрі, ієрархічній базі даних, схожій на ієрархічну файлову систему (ФС), але такій, шо дає змінним (аналогам файлів) типізовані клітини як одиниці постійного сховища, тоді як для файлових систем, файл — це завжди нетипізований контейнер. Тобто в реєстрі, надодачу до ключів, аналогів директорій, і змінних, останні мають тип, шо значить, шо їхні величини можуть бути лише з множини, яку цей тип визначає. Ця тонка структура, разом з відповідним програмним інтерфейсом для її доступу, дає ОС та програмам уніфікований та зручний механізм для зберігання своїх конфігураційних даних. Надодачу, двигун реєстру, Конфігураційний Менеджер, забезпечує журналювання цих даних, шо ґарантує їхню цілісність і захищеність від ушкоджень, спричинених неконтрольованим (абруптивним) перериванням операцій на реєстрі.
Фізично реєстр складається з реєстрових "вуликів" (англ. "hives") — файлів, які містять різні гілки (піддерева) реєстру. Подається ж реєстр як одне монолітне дерево, дерево реєстру, зібране з цих гілок. Тобто, продовжуючи аналогію з ФС, вулики — це аналоги томів (дисків), а дерево реєстру виступає як аналог єдиного дерева ФС на системах, які наслідують такий стиль подавання файлових даних, це т.зв. Unix стиль. Ant як і Windows використовує цей підхід для реєстру, але для файлових даних використовує інший метод. В ньому дерева томів показані кожен окремо, утворюючи ліс дерев. Розрізняються ці дерева присвоєнням ідентифікатору (напр. літери) кореневій директорії тому (диску), дивіться наступний абзац шодо специфіки Ant. Це так званий DOS стиль репрезентації ФС даних і для файлових даних, він видається зручнішим за монолітне дерево, бо ієрархія даних в цьому стилі показана ясніше й реальніше. Для реєстру з іншого боку, єдине дерево видається нормальним варіантом. Хоча, варто зазначити, шо можливість побудови реєстру як лісу потребує вивчення, цілком можливо, шо цей варіант видасться і тут вигіднішим.
Планується відтворити внутрішній формат реєстру як в Windows, а там як вийде.
Ant, як вже сказано, використовує DOS стиль для показування ФС даних. Відмінністю від Windows є те, шо ідентифікаторами суть не просто букви латинського алфавіту, а числа, закодовані як літерали цих чисел в 36-аковій (тридцятишостаковій), порядковій системі числення, побудованих на множині [0 - 9, A - Z]. Максимальна розрядність (довжина літералу в символах) планується 4. Такі рядки дають можливість уникнути нестачі літер на системах з кількістю дисків, яка переважає кількість наявних літер, адже з 4-розрядними числами, ми маємо ліміт в 364, шо є 1679616 — більше, ніж достатньо, плюс завжди легко розширити якшо не вистачить. Стара DOS схема є цілком сумісна з цією. Правильні ідентифікатори пробігають значення від 0 до ZZZZ (1679615). Передні нулі й регістр літер не важить. Приклад ФС шляхів з використанням правильних ідентифікаторів:
Останні два до речі, вказують на той самий том, і використовують одні з небагатьох зарезервованих системою ідентифікаторів. У цьому випадку, для системної партиції UEFI (ESP). Традиційно, Пусковий Том (англ. Boot Volume), — домівка ОС, отримує літеру C.
Насправді, є ціла специфікація задавання цих текстових URI-подібних адрес для ресурсів в ієрархічній, ФС-подібній структурі. Читайте тут за це детальніше.
Написана переважно мовою C з невеликою домішкою асемблерного коду. Перші цільові архітектури суть x86 і arm. Були також наміри включити в цільовий список mips і ppc, але обставини завадили цьому стати дійсністю. riscv також розглядалась оскільки Одноплатні Компутери (ОПК) або навіть ПК-подоби з нею почали з'являтися (26.05.2021). Але потім, в 2022 - 2023, все, крім x64 та arm64, було вилучено зі списку підтримки. Читайте цю сторінку для детальнішої ретроспективи.
Основне середовище ППЗ (Платформне Програмне Забезпечення, мій термін для англ. Firmware, бо використовувати неоковирну московську кальку з останнього "прошивка", я не можу) є Uefi. Можливі розглядані інші ППЗ були: стара Bios, Open Firmware, та, в "важких випадках", без-ППЗ-шне, голе середовище uboot, без будь яких сервісів, виставлених для вантажника. Знову, читайте сторінку Цільовий парк і середовище ППЗ, шоб взнати більше за цілі і ППЗ середовища, шо було залишено, шо закинуто і чого.
Також Ant має сильний акцент на підтримці кількох Підсистем Середовищ (ПС), тобто — мання здатности ганяти програми, написані для різних виконавчих середовищ, наборів API (стандартів). Основні суб'єкти суть WinAPI і Posix. Більше за це на сторінці Цілі ANT бо це велика тема сама по собі. Коротко, основна ПС, AntAPI, є WinAPI-подібною, наскільки подібною і повною, покаже час. Вона потрібна, наприклад, для будь якої програми з графічним інтерфейсом користувача (ГІК), бо саме ця ПС надає усю функціональність, пов'язану з графічним інтерфейсом. Насправді, всі програми режиму користувача залежатимуть від цієї ПС, явно чи неявно. Posix ПС забезпечуватиме можливість ганяти програми, які очікують цей стандарт API. Такі програми на Ант будуть лише з інтерфейсом командного рядка (ІКР). Насправді, Posix не покриває графічні інтерфейси і нема намірів портувати шось графічне з Unix клонів.
Заплановано мати розвинену систему керування інсталяційними пакетами програмних
комплексів або Інсталяційний Майданчик.
Для уникнення жахливого безладу, який неминуче з'являється без організованого,
добре визначеного механізму керування міріадами програм і їхніх даних, які
користувач ставе на машину.
Також для боротьби з роздуванням, яке йде в парі з згаданою кашею і походить
від чисельного множення тих самих речей, які ставляться різними сторонами як
залежності знову й знову.
Цей майданчик має бути потужним і дружнім до користувача одночасно. Шо,
звичайно, вказує, створення його — нелегке завдання. Обрисовуючи, користувачеві,
для ставлення чогось, треба взяти "пакет" того чогось, з довіреного джерела,
і пройти через його інсталяцію, використовуючи добревизначений набір утиліт,
чи то буде ІКР чи ГІК набір.
Програма, яка бажає бути встановленою, має підготувати встановчий пакет, у
визначений спосіб, вказуючи, чим вона є і від чого вона залежить.
Майданчик перевіре чи все добре з пакетом і зареєструє його в своїй базі даних.
Пакет має надавати користувачам зручну в користанні й зрозумілу інсталяційну
процедуру, можливість налаштовувати інсталяцію через опції, можливість ставити декілька
версій програми або вибір користувачів, для яких ця програма буде поставлена.
Це не має бути просто тупе
Очевидно, ця тема просе свою власну сторінку (шо буде зроблено пізніше, коли цей майданчик буде чимось явнішим, ніж туманна балаканина за нього).