Эндрю Шульман - Неофициальная Windows 95

Трапилася мені книжечка із далекого минулого, "Неофициальная Windows 95", проглядав її останні місяці, на пару із Таненбаумом, про якого пізніше. Такої "ніжності" та "ностальгії" як до FCB та DOS я до неї аж ніяк не відчуваю, тому детальної рецензії, як до "Extending DOS" by Ray Duncan et. al  не писатиму. Однак, дечим із неї поділитися хотілося б.

Кілька слів про саму книжку та предмет її обговорення. Вона, як видно з назви, присвячена Windows 95. Написана в ту епоху, коли цю операційну систему ще часто називало за ім'ям проекту, "Chicago" -- на момент виходу книги реліз ще не відбувся, автор працював із бета-версіями.

Автору 95-ка подобалася. Місцями -- надміру. Кумедно так читати щось типу: "на відміну від невиразної Windows NT", "Microsoft теж помиляється, поміж її невдач OS/2 та Windows NT", (не точні цитати, мій вільний переказ, хоч і близький до тексту), розповідь, що нічого особливо хорошого в чистій 32-бітній системі немає, а під 16-бітні (Windows 3.x та DOS) є купа коду, тому в найближчому майбутньому нікому чисті (нудні :-) NT не знадобляться і т.д.

Microsoft у той час активно наголошувала, що, у ядрі, Win95 (KERNEL32.DLL маючи на увазі), розірвала всілякі стосунки із DOS та 16-бітним режимом. Типу, 16-бітне ядро присутнє, але лише для зворотної сумісності із старим (legacy) кодом -- сама система до нього не звертається. (Офіційно згадувалося, що GDI32 i USER32 покладаються на своїх 16-бітних колег). Також стверджувалося, що Windows 95 -- зовсім нова операційна система, і т.д.

Автор вирішив детально розібрати, які насправді стосунки між DOS і Windows 95, як між собою взаємодіють ключові елементи Win-95 і коли вони насправді з'явилися. Тому що рекламні твердження Microsoft були неправильними, фактично -- прямим обманом. Хоча, відповідні інженерні рішення, в тих умовах, були обґрунтованими. Детально описувати не буду, через свою некомпетентність у відповідних питань, але в книзі показується, що:

• Фактично, Windows 95 містить в собі DOS захищеного режиму  -- див. розмови про WIN386 та DOSX.
• 32-бітний режим доступу до файлів яки автор називає 32BFA, (природне скорочення, хоч і не поширене в Інтернеті) були вже в Windows 3.11 (хоч це і був бекпорт з обговорюваного "Чікаго"). А 32-бітний доступ до диску, 32BDA, з'явився ще раніше, в 3.1.
• VMM, власне "суть і есенція" Windows 95 -- те, що робить цей продукт операційною системою, з'явився багато раніше, в Windows 3.0, а то і в Windows 2/386. Більше того, її можна назвати 32-бітним DOS захищеного режиму. (Див. також у Раймонда Чена: "32-bit DOS kernel", based on Win386 kernel, morphed into VMM32).
• Win32s, з точки зору автора -- цілком повноцінне Win32 API.
• Windows постійно звертається до DOS, а DOS до Windows, хоч і намагається обійтися без нього при файлових операціях -- користуючись 32BFA, IFSHLP.SYS/IFSMGR.VXD і т.д..
• І багато іншого.

При чому, свої висновки автор супроводжує кодом програм, які використовувалися для їх встановлення та перевірки, фрагментами дизасемблювання системного коду, "журналами" його виконання в дебаггері. Тобто, як мінімум, давав можливість читачам повторити його дорогу, навчитися чогось практично корисного (на той час) в процесі читання та експериментів -- те, чого так бракує багатьом науковим статтям. З іншого боку, в тексті кілька раз трапляється виправдання класу "ну, ви розумієте, це не зовсім та таблиця, що я хотів, але мені було лінь ще раз програму запустити в нових умовах" -- і мова не про різні об'єми вільного простору на дисках під час тестування віртуальної пам'яті, що якраз природно. 

Кращу рецензію можна почитати тут: "Book Review: Unauthorized Windows 95" -- вище лише коротка анотація, а розповідаю все це ось чому. Ближче до кінця книги автор детально розповідає, як 16-бітна та 32-бітна програма Clock працюватиме в 16-бітному (3.x) та 32-бітному (95) Windows. Зокрема, для 32/32-бітної комбінації показано, як відбувається обробка повідомлення WM_TIMER -- як програма оновлює час. І це -- неповторний шедевр! Найближче, де таке може зустрітися -- біологія. 

Див., наприклад, "Ахиллесова пята биологической сложности" на "биомолекуле": "Сложность устройства биомолекулярных систем многократно возрастает в ряду прокариоты → одноклеточные эукариоты → многоклеточные эукариоты, — и одновременно на многие порядки снижается размер популяций. Чем более высоко развит организм, тем сложнее устроена сеть взаимодействий белковых молекул между собой, — и, по-видимому, само возникновение многоклеточности обязано замысловатым белок–белковым взаимодействиям. Оригинальное компьютерное исследование структурной стабильности родственных белков из различных групп организмов показывает, что эта сложность может быть следствием не эволюционных адаптаций, а «залатыванием» белковых дефектов, постепенно накапливающихся в популяциях ограниченного размера под действием генетического дрейфа." Певне і в розвитку програмних продуктів працює якийсь схожий закон. Або це різні прояви якогось єдиного закону розвитку складних систем.

Зразу все просто і звично:

• Отримавши повідомлення WM_TIMER, Clock викликає GetLocalTime() з Win API
• Та, у свою чергу, викликає недокументовану (тоді?) VxCall0
• Виклик цей перехоплюється VMM

Разом воно виглядає якось так:

Рис. 14.2 з книги "Неофициальная Windows 95"

Зворотній виклик внизу займається декодуванням сервісу Windows, та, (sic!) передачу його славнозвісному int 21h, конкретніше, функції 2Ah та 2Ch -- отримати дату та час:

Рис. 14.3 з книги "Неофициальная Windows 95"

Тобто, Windows 95, для виконання своєї роботи викликає DOS? Як на той момент автор показує не раз, і так і ні. Далі відбувається складний процес перевірки, чи якийсь із перехоплювачів int 21h не хоче опрацювати цей виклик:

Рис. 14.4 з книги "Неофициальная Windows 95"

Якщо ніхто їх не перехопив (що типово для не особливо "засміченого" стороннім софтом Windows 95), в кінці виклик потрапляє DOS. 

Однак, весело тут тільки починає робитися. DOS виконується у віртуальній машині, в режимі Virtual x86, коли DOS-івський драйвер CLOCK$ викликає int 1Ah, переривання BIOS отримання системного часу, воно знову перехоплюється VMM та, нарешті, перенаправляється віртуальному драйверу таймера, VTD:

Рис. 14.5 з книги "Неофициальная Windows 95"

Все, час отримано. А тепер назад (ну, оминаючи перехоплювачі, звичайно) -- передати інформацію тому, хто викликав. Тобто, повернутися в DOS і т.д.

Менш-більш зрозуміло, чому зроблено саме так (особливо після прочитання книги, що обговорюється), але, кому-як, а мені страшно від такого петляння в процесі простого виклику. (Згідно тієї ж книжки, 16-бітний Clock під 16-бітний Windows просто викличе відповідні функції DOS, який звернеться до BIOS і поверне результат, хоч і це відбуватиметься із залученням VMM -- режим все той же virtual x86). Цікаво, як воно в NT відбувається? (Але, через обмеження по силах і часу, не настільки, щоб спеціально виясняти...)

Висновку не буде, просто не міг не поділитися -- побоявся вибухнути від надміру емоцій. :-) Книжка легко знаходиться в Інтернеті та коштує (б/в) копійки на Амазоні -- читайте під настрій. Хоча, пам'ятайте, практична її цінність зараз нульова, до від'ємної.