• Предмет книг
• “Inside OS/2”
  • Вміст
  • Зміст
• “Advanced Os/2 Programming”
  • Вміст
  • Цікавинки
  • Зміст
• Підсумок
• Посилання
• Виноски

Продовжуючи серію ретро-літоглядів, хочу розповісти про дві книги, присвячені OS/2¹: “Inside OS/2” by Gordon Letwin, 1988 та “Advanced Os/2 Programming” by Ray Duncan, 1989.

Вони зовсім протилежні за призначенням. Друга – глибоко прагматична, а перша – навпаки, більше про ідею і принципи. Іншими словами, вони взаємно доповнюють одна одну.

Предмет книг

Дуже коротко про тему цих книг, OS/2. Це багатозадачна однокористувацька операційна система. Розпочалася як плід дружби IBM та Microsoft, потім розвивалася IBM, але з часом програла іншим ОС загального використання. Існує досі, як спеціалізована, з назвою ArcaOS.

Поміж іншого, була чи не першою масовою ОС з підтримкою потоків – напишу про це окремо.

Розпочинала своє життя як 16-бітова система для 286 – через дивні тогочасні ідеї IBM. Такими залишалися версії 1.xx – 2.xx і наступні вже були 32-бітовими². Обидві книги стосуються якраз 16-бітових варіантів OS/2 – 32-бітова з’явилася вже в 1991-1992.

• “Inside OS/2” згадує лише версію 1.00 (грудень 1987).
• “Advanced Os/2 Programming” вже знає про 1.10 (листопад 1988, при тому, що книжка містить передмову від грудня 1988) – ту, що з GUI, але говорити про GUI автор уникає.

Переходимо до огляду книг.

“Inside OS/2”

Вміст

Автором є головний архітектор (lead architect) OS/2, тому він зосередився на ідеях, закладених в операційну систему (ОС), уникаючи подробиць, таких як описи API чи спроб вчити програмувати.

В книзі триста сторінок та 20 глав, що поділені на три частини:

• Загальний опис проекту – з чого починалося, чому, як.
• Опис архітектури – багатозадачність, потоки та пріоритети, засоби синхронізації, динамічне зв’язування, файлові системи, керування пам’яттю та IPC (Inter-process communication), монітори пристроїв, підходи до користувацького інтерфейсу, засоби зневадження. Іншими словами, автор описує, які засоби, зі всього спектру запропонованих різними системами та науковими публікаціями засобів, обрано авторами системи і чому. Зауважте, цей набір актуальний, принаймні на рівні ідей, і в 2024.
• Плани на майбутнє. Завжди кумедно їх читати в комп’ютерних ретрокнигах.

Детально переказувати її вміст мені не цікаво (та й, зізнаюся, читав вже кілька років тому), та й моїм читачам певне теж не дуже буде, тому зосереджуся на цікавинках.

Багато уваги приділяється зворотній сумісності – все ж, DOS була, з одного боку, фантастично популярною, з іншого – дуже складною в розширенні³. Це вже котра книга, про яку розповідаю, присвячена вирішенню проблеми – як розвиватися далі, зберігаючи сумісність з DOS…

Розповідь, чому потоки корисні і як їх використовувати, (розділ 5, зокрема 5.1.2 та 5.1.3), дуже нагадує те, як можна про них розповідати і зараз – хоча для професіонала зараз вже звучатиме наївно.

Аналогічно, обговорюється (стор. 97) проблема position-independent коду (PIC) – досі важлива. Розказано, як вона вирішувалася, з використанням сегментів 286 та за наявності LDT⁴. Поруч – обговорення релокацій. Проблема, яка на сучасних ОС вирішується за допомогою GOT i PLT⁵, теж вирішується акуратним вибором селекторів (індексів у таблиці сегментів) для сегментів даних. До речі, і PIC і релокації, навіть для сучасних ОС, залишаються одними з найскладніших для сприйняття студентами тем на відповідному курсі.

Щодо LDT, GDT, сегментів тощо – детальні пояснення див. “Уроки захищеного режиму”.

Ще одна, знайома за сучасними ОС, ідея: на сторінці 144 описано infosegs – спеціальні сегменти з системною інформацією (глобальний і локальні). Там міститься, наприклад, поточні дата та час, оновлювані ОС та доступні процесам лише для читання. В Linux ту ж проблему вирішує дуже схожим ідейно, але дуже відмінним технічно способом – vDSO.

На сторінці 152 піднімається тема потреби в двох видах семафорів: RAM-семафор не потребує звертання до ядра під час захоплення не захопленого семафору чи його повернення та системні семафори, які завжди функціонують, звертаючись до ядра. Обидва типи примітивів синхронізації, разом з їх варіаціями, ми вивчаємо із студентами, коли вчимося писати ефективні паралельні програми – futex-и, адаптивні м’ютекси, спінлоки все таке.

Читаючи 170-ту чи й 296-297 сторінки, бачимо, що сигнали OS/2 дуже схожі на сучасні їй сигнали Unix. Однак, видно, що автори знайомі з їх проблемами, зокрема – передчасним завершенням “довгих” системних викликів (та наслідком цього, типу partial read/partial write), і намагаються їх вирішити. Зокрема, сигнали завжди обробляє потік-1 (той, що з’являється першим, під час запуску програми), а перериватися можуть лише ‘‘повільні’’ пристрої, такі як клавіатура – диски вважаються швидкими, до чого і сучасний Linux прийшов.

Unix-и, в певній мірі, досі з цим страждають:

Під Linux, дискові read() i write() не мають спричиняти EINTR:

read(2), readv(2), write(2), writev(2), and ioctl(2) calls on “slow” devices. A “slow” device is one where the I/O call may block for an indefinite time, for example, a terminal, pipe, or socket. If an I/O call on a slow device has already transferred some data by the time it is interrupted by a signal handler, then the call will return a success status (normally, the number of bytes transferred). Note that a (local) disk is not a slow device according to this definition; I/O operations on disk devices are not interrupted by signals.

Але, якщо “диск” це Network File System (NFS) диск – EINTR може траплятися, див. “A brief history of union mounts”. Також, в теорії, write(), але не read(), може давати EINTR на FreeBSD та MacOS. Однак, це особливості конкретних систем – POSIX не дає таких гарантій.

Монітори пристроїв, (розділ 16.1) дозволяють опрацьовувати потоки даних драйвері з user-space – дуже просунутий засіб. Зокрема, моніторів у ланцюжку може бути декілька – якщо драйвер та інші монітори, які вже у ньому, не заперечують. В світі Linux варто згадати FUSE – Filesystem in Userspace – значно більш ‘‘молодий’’ засіб.

Розділ про стани гонитви (race conditions) цікаво називається – ‘‘Data integrity’’.

Проблема FAT як надійної файлової системи у випадку збоїв, наприклад, непередбачуваних вимкнень, описана (наприклад, стор. 216), але альтернатив тоді не пропонувалося⁶, хіба обговорювалося їх потребу – і з точки зору безпеки, і з точки зору зручності – хіба ж це не знущання, імене розміру 8+3?, (розділ 21.1 і, зокрема, стор. 264). Зачіпається потреба в installable file systems, як необхідному засобу досягнення гнучкості.

В кінці книга хвалиться, що форматувалася в Microsoft Word, а шрифт – Times Roman.

Читається легко, і вкотре нагадувала мені, що основні ідеї ОС закладені давно – лише надбудовуються, уточнюються, покращуються. Оці ось віртуалізація, ізоляція процесів та стійкість самої ОС до їх ‘‘капризів’’, їх диспетчеризація і синхронізація, віртуальна пам’ять – як одна з передумов гнучкості, потреба якось організовувати перманентне сховище тощо.

В цілому – мені книга сподобалася, рекомендую зацікавленим в історії комп’ютерів! Але початківцям, що вивчають комп’ютерну інженерію, може бути шкідливою – ідеї, хоча й приблизно ті ж, в сучасному світі трансформувалися, акценти змістилися – можна виробити невірні уявлення, якщо це буде перша книга про ОС.

Зміст

• Foreword by Bill Gates
• Introduction
• Part I: The Project
  • Chapter 1. History of the Project
    • 1.1 MS-DOS version 1.0
    • 1.2 MS-DOS version 2.0
    • 1.3 MS-DOS version 3.0
    • 1.4 MS-DOS version 4.0
  • Chapter 2. Goals and Compatibility Issues
    • 2.1 Goals
    • 2.2 Compatibility Issues
  • Chapter 3. The OS/2 Religion
    • 3.1 Maximum Flexibility
    • 3.2 A Stable Environment
    • 3.3 Localization of Errors
    • 3.4 Software Tools Approach
• Part II: The Architecture
  • Chapter 4. Multitasking
    • 4.1 Subtask Model
    • 4.2 PIDs and Command Subtrees
    • 4.3 DosExecPgm
    • 4.4 DosCWait
    • 4.5 Control of Child Tasks and Command Subtrees
  • Chapter 5. Threads and Scheduler/Priorities
    • 5.1 Threads
    • 5.2 Scheduler/Priorities
  • Chapter 6. The User Interface
    • 6.1 VIO User Interface
    • 6.2 The Presentation Manager User Interface
    • 6.3 Presentation Manager and VIO Compatibility
    • Chapter 7. Dynamic Linking
    • 7.1 Static Linking
    • 7.2 Loadtime Dynamic Linking
    • 7.3 Runtime Dynamic Linking
    • 7.4 Dynlinks, Processes, and Threads
    • 7.5 Data
    • 7.6 Dynamic Link Packages As Subroutines
    • 7.7 Subsystems
    • 7.8 Dynamic Links As Interfaces to Other Processes
    • 7.9 Dynamic Links As Interfaces to the Kernel
    • 7.10 The Architectural Role of Dynamic Links
    • 7.11 Implementation Details
    • 7.12 Dynlink Names
  • Chapter 8. File System Name Space
    • 8.1 Filenames
    • 8.2 Network Access
    • 8.3 Name Generation and Compatibility
    • 8.4 Permissions
    • 8.5 Other Objects in the File System Name Space
  • Chapter 9. Memory Management
    • 9.1 Protection Model
    • 9.2 Memory Management API
    • 9.3 Segment Swapping
    • 9.4 Status and Information
  • Chapter 10. Environment Strings
  • Chapter 11. Interprocess Communication
    • 11.1 Shared Memory
    • 11.2 Semaphores
    • 11.3 Named Pipes
    • 11.4 Queues
    • 11.5 Dynamic Data Exchange (DDE)
    • 11.6 Signaling
    • 11.7 Combining IPC Forms
  • Chapter 12. Signals
  • Chapter 13. The Presentation Manager and VIO
    • 13.1 Choosing Between PM and VIO
    • 13.2 Background I/O
    • 13.3 Graphics Under VIO
  • Chapter 14. Interactive Programs
    • 14.1 I/O Architecture
    • 14.2 Ctrl-C and Ctrl-Break Handling
  • Chapter 15. The File System
    • 15.1 The OS/2 File System
    • 15.2 Media Volume Management
    • 15.3 I/O Efficiency
  • Chapter 16. Device Monitors, Data Integrity, and Timer Services
    • 16.1 Device Monitors
    • 16.2 Data Integrity
    • 16.3 Timer Services
  • Chapter 17. Device Drivers and Hard Errors
    • 17.1 Device Drivers
    • 17.2 Hard Errors
  • Chapter 18. I/O Privilege Mechanism and Debugging/Ptrace
    • 18.1 I/O Privilege Mechanism
    • 18.2 Debugging/Ptrace
  • Chapter 19. The 3x Box
  • Chapter 20. Family API
• Part III: The Future
  • Chapter 21. The Future
    • 21.1 File System
    • 21.2 The 80386
    • 21.3 The Next Ten Years
• Glossary
• Index

“Advanced Os/2 Programming”

Вміст

Автор, Ray Duncan⁷ – людина відома в світі програмування під DOS, ще не раз оглядатиму його книги. Але відзначився й парою праць про інші продукти Microsoft.

Ця книга більш прагматична – вчить програмувати під OS/2 (16-бітові). Охоплено практично все, від текстового UI, до написання моніторів пристроїв та драйверів. Хіба що програмування GUI (‘‘програмування для Presentation manager’’, хоча API достатньо схоже на WinAPI тієї епохи) не розглядалося.

Вона дещо нуднувата, в порівнянні з попередньою – не зважаючи на талант автора, сама задача спонукає. Хіба що трохи дратувала характерна особливість: абсолютна більшість прикладів, як і в інших книгах автора, написана на асемблері. З одного боку, це було б помічним, якби я вчився по ній програмувати у той час. З іншого, на відміну від DOS, API OS/2 базується на С, тому простирадло за простирадлом асемблерного коду займається вдовільнянням угод про виклики Microsoft C відповідної версії. Принаймні зараз мені було б простіше розгортати код на C у відповідний асемблерний код, ніж реконструювати прототипи функцій (і логіку коду) з тих асемблерних простирадл.

Попередній власник, здається, поставив собі за ціль підкреслити взагалі всі рядки в книжці – принаймні, в окремих розділах. Виявилося, що це доволі сильно відволікає…

В книжці все ще є купон на замовлення диску – вже котрий в мене, є спокуса колись та вислати в Microsoft і подивитися, що буде – доживу до перемоги, так і зроблю. :-)

“Advanced Os/2 Programming” помітно товстіша за попередню – більше 782 сторінок, сім розділів розділів, які включають 19 глав, три довідкових розділи та п’ять додатків:

• Огляд OS/2: коротка розповідь про ідеї, викладені більш детально в “Inside OS/2”, трішки подробиць про структуру і запуск самої OS/2, її карту пам’яті тощо.
  • Окреслює загальну структуру, як на рівні коду, так і на рівні об’єктних файлів і фінальних виконавчих файлів.
  • Також, описано процес ініціалізації процесу та його взаємодії з API.
  • Розповідається про Family API – функції, сумісні з DOS, якщо програма використовує тільки їх, вона зможе виконуватися під обома ОС нативно.
  • Одна глава присвячена того, що ми зараз називаємо toolchain – компілятором, асемблером, лінкером, менеджером бібліотек, Make – знову ж, те що доводиться викладати і сучасним студентам.
  • Приклад лише на асемблері.
• Вступ до прикладного програмування.
  • Програмування текстового користувацького інтерфейсу – читання клавіатури та мишки, робота з дисплеєм, (але про графічні можливості дуже побіжно), принтери та послідовні порти, сховище, файли та файлові системи.
  • Згадуються відповідні монітори пристроїв і потоки даних від драйверів пристроїв, через ядро, до низькорівневих та високорівневих динамічних бібліотек з користувацького простору.
  • Приклади на асемблері, хіба для роботи з файлом і директоріями – на С, при чому, функції API оголошуються безпосередньо в тілі програми – автор був у курсі неземних цін на OS/2 SDK⁸?.. Чи там були інші причини?
  • Також, у цьому розділі чомусь є глава про внутрішню організацію дисків – оті всякі MBR-BOOT-FAT, коротко показано, як звертатися до дисків на низькому рівні – для цього їх потрібно відкрити, як файл, з прапорцем DASD⁹ та заблокувати.
  • Згадуються файлові блокування – ще один засіб з POSIX (хоча, не пам’ятаю часу їх появи там).
• Професійні теми.
  • Керування пам’яттю – як низькорівневі подробиці, так і прикладні API. Власне, низькорівневі подробиці трохи потрібні – через обмеження ресурсів, доводиться турбуватися про всілякі дивні, з прикладної точки зору, поняття, типу Discardable Segments.
  • API для керування процесами та потоками. Як приклад наведено командний інтерпретатор (на асемблері) та термінал (двічі, на С та на асемблері).
  • Засоби IPC – семафори, канали (pipe) – анонімні та іменовані, спільна пам’ять (shared memory), черги, сигнали. Теж все – дуже знайомі й сучасним програмістам теми. Та й вплив Unix дуже відчувається.
  • IOPL-сегменти – унікальний засіб OS/2, щоб надати прикладним програмам можливість безпосередньо працювати з апаратними пристроями: DOS не міг обмежити, а інші ОС, зазвичай, взагалі такого не дозволяють. Це знову був компроміс між безпекою, гнучкістю, зворотною сумісністю і швидкодією, в умовах доволі обмежених апаратних ресурсів. (Приклад – читання перших 256-ти портів, на асемблері та С).
  • Дещо прозаїчніша тема – керування часом, датою та таймери. Зокрема, показано, як користуватися Infoseg, про які я згадував вище, в огляді ‘‘Inside OS/2’’. API там цікаве – програма, яка має виконати якусь дію за таймером, блокується на семафорі, який розблоковує системний таймер.
  • Описано, з прикладами, як писати фільтри.
  • Розказано, як перенаправляти ввід-вивід для фільтрів – процедура ідейно схожа, але, враховуючи відсутність fork(), відрізняється від звичної в POSIX (див. стор. 340), включає танці з перевідкриванням консолі.
  • Окрема глава цього розділу присвячена написанню драйверів. Глава перераховує достатньо детально (майже?) всі коди команд. Наводиться приклад, що містить всі частини символьного драйвера та приклад драйверу блокового пристрою (на асемблері).
  • Описуються функції бібліотеки DevHlps, які дозволяють драйверу взаємодіяти з ОС та іншими драйверами¹⁰ – вони, на відміну від драйверів DOS не повинні жити повністю самостійно.
  • Описано методологію розробки драйверів на різних рівнях абстракції.
  • Багато мови йде про ‘‘гібридні’’ драйвери – здатні працювати і в захищеному, і в реальному режимі – такий собі костиль (який катастрофічно ускладнив розробку драйверів для OS/2), щоб підтримувати виконання програм DOS на 286-му процесорі і мінімізувати переключення між режимами, які на ньому дуже дорогі. Зокрема – бімодальні вказівники, коректні в обох режимах, та функції перетворення між віртуальною та фізичною адресою, дозволяючи доступатися до даних, незалежно від режиму процесора. Всілякі жахіття – див. у додатку функції, типу PhysToVirt() та ProtToReal(), та використання недокументованих фокусів – LOADALL, щоб доступатися з реального режиму до пам’яті вище 1 Мб (наприклад, див. стор. 676). Воно все настільки складне і плутане (хоча й зрозуміло, чому таке), що не дивно – розробники не дуже любили писати драйвери для цієї ОС…
  • Інша глава присвячена розробці моніторів пристроїв – таких-собі user-space драйверів. Приклад – монітор, що робить текстові скріншоти за натискання певної клавіші (на асемблері та на С).
  • Також, розглядаються динамічні бібліотеки – навіщо вони, як працюють, як розробляти. Цікава епоха, коли автор (стор. 464) обговорює угоди про виклики функцій з бібліотек і (лише!) радить дотримуватися тих же угод, що в kernel API…
• Розділ довідки описує API ядра, доступні прикладним програмам, DosDevIOCtl – для керування властивостями пристроїв, що виходять за межі роботи з ними, як з файлами та функції DevHlps для драйверів – до епохи Інтернету дуже класно було це мати під руками, навіть коли зв’язку чи й комп’ютера з цифровою довідкою під руками немає.
• Додатки: коди помилок, ASCII-таблиця, список літератури, формат виконавчих файлів – New Executable, синтаксис оголошення модулів.

В кінці теж скаржиться хвалиться, що створена в Microsoft Word.

Цікавинки

Напишу про подробиці, які зацікавили під час читання. Ці твердження стосуються лише версій 1.00 та 1.10 – новіші можуть поводитися по іншому.

Цікаво, що імена функцій починаються з Dos: DosOpen(), DosWrite() тощо.

DosWrite()/DosRead() не повертають помилку, якщо записали/прочитали більше, ніж запитано – просто повідомляє, скільки байт опрацьовано. Однак, на відміну від аналогів в POSIX-системах, причиною цього може бути лише недостача місця на диску або даних у файлі. Ці функції синхронні, а їх асинхронні варіанти, DosWriteAsync()/DosReadAsync(), повідомляють про завершення за допомогою RAM-семафору – на початку функції його захоплюють, а коли дія завершена, ядро його віддає. А реалізація, на наш час, дещо кумедна (хоча, такий підхід все ще використовується іноді) – створюється окремий потік, який знищується після завершення операції вводу-виводу.

Пошук файлів відбувається звичними (для DOS) DosFindFirst()/DosFindNext()/DosFindClose() – і сказано, що хоча кожен процес має (в тих версіях OS/2) 1000 дескрипторів для пошуку (стор. 169), варто, все ж, закривати їх – певне, як зіслання на відомі проблеми з не закритими FCB, які створювали величезні проблеми для мережі в DOS.

Цікавим є розгляд Huge Memory Blocks – підходу, як створити блок пам’яті, позірно більший за 64 Кб – максимальний розмір сегменту на 286¹¹. Для цього функції DosAllocHuge потрібно передати, окрім потрібного розміру, також максимальний розмір сегменту, до якого він може зрости. Тоді OS зберігає сегменти в сусідніх селекторах LDT, та надає величину (DosGetHugeShift(), в Infoseg та динамічному символі Huge_Shift), на яку слід збільшити селектор, щоб перейти до наступного сегменту, позірно прозоро для коду на C. Як це в асемблерному коді – показано в прикладі. Але трішки бракує прикладу, як з тим працювати в коді на С для компіляторів, які нічого не знають про цю магію… Поруч є також опис і приклад роботи з Discardable segments – сегментами, які можна вільно відновити, і тому немає потреби зберігати у swap – та ж ідея, підозрюю – помітно агресивніше, використовувалася і в 16-бітових Windows. Ще один розділ описує, як писати в сегменти коду – власне, використовуючи синонімічні сегменти даних, теж з прикладом.

Багато рекламуються потоки, але про їх API писатиму окремо – воно хвореньке, особливо – в 16-бітовому варіанті. Зокрема, стек потрібно створювати вручну, немає засобів передати аргумент у функцію, яка буде виконуватися в потоці, зате можна призупинити і відновити виконання потоку ззовні нього. Приклади на асемблері – задумався, що, до свого сорому, я ще не писав жодної багатопоточної програми на асемблері… Також, структури даних для підтримки потоків виділяються статично, максимальна кількість потоків у системі задається в CONFIG.SYS – між 16 і 255, за замовчуванням 64 в OS/2 1.00 i 128 в 1.10. Невже десь байт в ролі індексу? В будь якому випадку, не ті числа, до яких ми зараз звикли… Ще один цікавий параметр – MAXWAIT – максимальний час очікування потоку на виконання, 1-255 секунд. Також, можна керувати квантом часу і наявністю динамічних пріоритетів.

Код IOPL-сегментів виконувався на рівні захисту (ring) 2, це ж значення було в полі IOPL регістру EFLAGS, дозволяючи цьому коду працювати з портами вводу-виводу – звідти й, певне, назва. Використовувати такі сегменти можна заборонити з CONFIG.SYS.

Опис динамічних бібліотек – дуже знайомий, хіба що – IOPL-сегментів у сучасних динамічних бібліотеках спільного використання не буває. Хвалиться книга, що ідея була випробувана на Windows навіть в реальному режимі. В цілому, проблеми і особливості достатньо схожі на відомі з (16-бітових) Windows. Проблема релокації вирішується тим, що кожен процес, який її завантажив, використовує той же дескриптор LDT для сегменту даних у всіх процесах – кажуть, ексклюзив OS/2 тоді…

Сподобалося формулювання про anonymous pipes (стор. 280) – ‘‘вони, за потужністю, між семафорами і чергами’’. Хоча анонімні канали тут такі ж, як і в POSIX, але нам таке використання звучить незвично.

Спільна пам’ять підтримується у двох виглядах: іменованих сегментів, та передавання (giving) або отримання (getting) їх селекторів за допомогою засобів IPC. Згадав, як ми можемо в POSIX міжпроцесні семафори передавати… Що незвично, віддавати або отримувати сегменти – це різні способи. DosGiveSeg() створює відповідний селектор в LDT процесу-отримувача. Його й потрібно передати отримувачу. Коли створюється сегмент, який можна отримувати (gettable), навпаки, резервує один і той же дескриптор у LDT всіх процесів у системі. Маючи цей номер, процес-отримувач може побудувати відповідний дескриптор у своїй LDT за допомогою DosGetSeg(). Це дозволяє вільно використовувати FAR-вказівники, не заморочуючись – в якому ти процесі, але вразливе для зловживання, а, з сучасної точки зору – і до вичерпання ресурсів.

Бімодальні вказівники – цікаве збочення чи костиль. Вони організовані так, що селектор захищеного режиму збігається з сегментом реального, тому та ж адреса дозволяє доступ до тієї ж пам’яті в обох режимах. Звичайно, такі вказівники ОС може створювати лише на дані, якими володіє, і вони мають знаходитися у нижньому мегабайті (книга стверджує – в нижніх 640 Кб, але не знаю, чи автор не подумав про UMB, чи справді є таке обмеження десь в іншому місці ОС).

Я давно підозрював, що, хоча структура драйверів DOS, спроектована трохи завчасно, не прижилася у Windows, але десь ще мала б залишити свій слід. З книги видно, що драйвери OS/2 успадковувалися від моделі драйверів DOS. Драйвер, як і в DOS, має стратегічну підпрограму та підпрограму обробки переривань – але тут вони реально потрібні. Їх поділ нагадує top i bottom частини драйверів сучасних ОС. Стратегічна підпрограма викликається, коли ініціюється операція вводу-виводу, отримує пакет запиту, як бімодальний вказівник, і драйвер має підтримувати відповідну чергу запитів. Підпрограма обробки переривань викликається, коли є переривання від пристрою, який обслуговується драйвером. Вона, на завершення, дивиться в чергу запитів, і якщо є нові – відправляє на виконання. Переривання мультиплексуються (думаю, казати – віртуалізуються, буде перебільшенням) ядром ОС.

В додатку (стор. 740) описано типи виконавчих файлів, які можуть бути в описі модулів, і там згадано такі значення EXETYPE:

• OS2 – Microsoft OS/2 version 1.0 or later
• WINDOWS – Microsoft Windows
• DOS4 – Multitasking MS-DOS (currently sold only by European OEMs, not the same as the USA MS-DOS/PC-DOS version 4).

Десь ми останній пункт бачили…

Зміст

• (Section 0):
  • Road Map to Important Figures and Tables
  • Acknowledgments
  • Introduction
• SECTION ONE: THE OS/2 OPERATING SYSTEM
  • CHAPTER ONE: INTRODUCTION TO OS/2
    • System positioning; Key features of OS/2
  • CHAPTER TWO: OS/2 STRUCTURE AND INITIALIZATION 11
    • System components; How OS/2 is loaded; Memory maps
  • CHAPTER THREE: OS/2 APPLICATION PROGRAMS
    • Program source structure; Module definition files; Executable file structure; Program loading, entry conditions, and termination; Sample program: HELLO.ASM
  • CHAPTER FOUR: OS/2 PROGRAMMING TOOLS
    • File types and extensions; Macro Assembler; C Compiler; Linker; CREF utility; Librarian; BIND and API.LIB; MAKE utility
• SECTION TWO: PROGRAMMING THE USER INTERFACE
  • CHAPTER FIVE: KEYBOARD AND MOUSE INPUT
    • Keyboard modes; Keyboard input methods; Use of logical keyboards; Keyboard subsystems and drivers; Keyboard monitors; Mouse input methods; Mouse subsystems and drivers; Sample program: MOUDEMO.C
  • CHAPTER SIX: THE VIDEO DISPLAY
    • Video display modes; Using DosWrite output; Using Vio functions for output; Popup support; Video subsystems and drivers
  • CHAPTER SEVEN: PRINTER AND SERIAL PORTS
    • Printer output methods; The print spooler; Serial port input and output; Configuring the serial port; The serial port and real mode applications
• SECTION THREE: PROGRAMMING MASS STORAGE
  • CHAPTER EIGHT: FILE MANAGEMENT
    • Filenames and handles; Opening, creating, and closing files; Reading and writing files; Forcing disk updates; File and record locking; Sample programs: ARGC.ASM, ARGV.ASM, DUMPC, DUMP.ASM
  • CHAPTER NINE: VOLUMES AND DIRECTORIES
    • Hierarchical directory structures; Searching disk directories; Directory and disk control; Volume labels; Sample programs: WHEREIS.C and WHEREIS.ASM
  • CHAPTER TEN: DISK INTERNALS
    • Boot sector and BIOS parameter block; File allocation table; Root directory; Files area and subdirectories; Fixed disk partitions; Direct disk access
• SECTION FOUR: ADVANCED OS/2 TECHNIQUES
  • CHAPTER ELEVEN: MEMORY MANAGEMENT
    • Memory protection; Virtual memory; Allocating global memory; Huge memory blocks; Discardable segments; Writable code segments; Local storage
  • CHAPTER TWELVE: MULTITASKING
    • The OSD scheduler; Managing processes; Managing threads; Managing sessions; Configuring the OSD multitasker; Sample programs: TINYCMD.C, TINYCMD.ASM, DUMBTERM.C, DUMBTERM.ASM
  • CHAPTER THIRTEEN: INTERPROCESS COMMUNICATION
    • Semaphores; Pipes; Shared memory; Queues; Signals
  • CHAPTER FOURTEEN: IOPL SEGMENTS
    • Execution with 1/0 privilege; IOPL-related API functions; Using IOPL in applications; Sample programs: PORTS.C, PORTS.ASM, PORTIO.ASM
  • CHAPTER FIFTEEN: TIME, DATE, AND TIMERS
    • Reading and setting date and time; Programmed delays; Using timers
• SECTION FIVE: CUSTOMIZING OS/2
  • CHAPTER SIXTEEN: FILTERS
    • System support for filters; Building simple filters; Using a filter as a child process; Sample programs: PROTO.C, PROTO.ASM, FIND.C, EXECSORT.ASM
  • CHAPTER SEVENTEEN: DEVICE DRIVERS
    • Unique aspects of OS/2 drivers; Device driver types and modes; Device driver structure; Command code functions; Device Driver Helper functions (DevHlps); Building a device driver; Sample programs: TEMPE ATE. ASM, TINYDISK.ASM
  • CHAPTER EIGHTEEN: DEVICE MONITORS
    • Monitor organization; Monitor data packets; Device driver support for monitors; Sample programs: SNAP.C, SNAP.ASM
  • CHAPTER NINETEEN: DYNAMIC LINK LIBRARIES
    • Dynamic linking at load time; Dynamic linking at run time; Writing DLLs in assembly language; Writing DLLs in C; Sample programs: ASMHELPASM, SHOWARGS.ASM, CDLL.C, CIN1T.ASM
• SECTION SIX: OS/2 REFERENCE
  • PART ONE: KERNEL API
  • PART TWO: DosDevIOCtl FUNCTIONS
  • PART THREE: DevHlp FUNCTIONS
• SECTION SEVEN: APPENDIXES
  • APPENDIX A: OS/2 ERROR CODES
  • APPENDIX B: ASCII AND IBM EXTENDED CHARACTER SETS
  • APPENDIX C: RESOURCES
  • APPENDIX D: OS/2 LOAD MODULE FORMAT
  • APPENDIX E: MODULE DEFINITION FILE SYNTAX
• Glossary
• Index

Підсумок

Обидві книги можна знайти в Інтернеті (або, якщо трішки почекати-пополювати, купити за кілька доларів на Амазоні), але якщо вам не вдалося – пишіть, поділюся.

Отримав масу задоволення, майже як від читання фантастики – але й користі певне десь стільки ж.

Посилання

• The OS/2 API Project
• https://komh.github.io/os2books/ – велика колекція книг
• '’Design of OS/2’’ by Deitel and Kogan, 1991, яка вже згадує і 32-бітові варіанти цієї OS.
• https://os2museum.com/ – сайт історії OS/2, DOS та інших подібних продуктів.
• “Inside OS/2” на веб-архіві.
• “Advanced Os/2 Programming” на веб-архіві.
• '’The History of OS/2’’ – ще одна версія викладу історії.

Виноски