в упакованном виде чуть больше
Ядро исполняемой системы (dw32core.zip), занимающее в упакованном виде чуть больше 100 Кбайт (!), — это все, что нам нужно для нормальной работы. В этот крохотный объем Харону удалось втиснуть:
q полноценный DPMI-расширитель, переводящий процессор в защищенный режим, поддерживающий виртуальную память (включая подкачку на диск!), и содержащий "переходники" из защищенного режима к функциям MS-DOS;
q загрузчик PE-файлов, "переваривающий" как исполняемые файлы, так и динамические библиотеки (DLL);
q основные системные функции базовых Windows-библиотек: ernel32.dll, user32.dll, advapi32.dll, ole32.dll, shell32.dll, mpr.dll, ntdll.dll, version.dll, winmm.dll, oleaut32.dll, rpcrt4.dll, winspool.drv, gdi32.dll (разумеется, реализован не полный набор точек входа — для консольных задач полный и не нужен, а места требуется много. к тому же, многие точки входа "реализованы" в виде "заглушек", состоящих из одного только return ERROR_CALL_NOT_IMPLMENTED, return ERROR_INVALID_HANDLE и т. д. Это — "патентованная" технология Windows 9x — объявить функцию в SDK и тут же "заткнуть" ее, чтобы никто не использовал);
q реестр и ini-файлы (функции реестра реализованы не слишком производительно и работа с большими объемами данных вызывает определенные тормоза, так же сохранение изменений на диск происходит либо только по явному запросу RegFlushKey, либо по завершению процесса);
q буфер обмена
(поддерживаются только форматы CF_TEXT, CF_OEMTEXT и RegisterClipboardFormat, причем перекодировка между форматами не проводится, поскольку ANSI-codepage OEM-codepage всезде одинаковые);
А вот список того, чего здесь нет:
q многозадачности/многопоточности
(вызов CreateThread не реализован);
q раздельных адресных пространств (все задачи выполняются в единой области памяти, что в частности, делает невозможным запуск из FAR'а программ без релокаций, поскольку они хотят исполняться в уже занятым FAR'ом регионе памяти и не могут быть перемещены на другое место, ведь таблицы перемещаемых элементов у них нет);
q сети
(библиотека WINSOCK.DLL в doswin32 не реализована, а это значит, что мы не можем взаимодействовать с сетью "напрямую", тем не менее какая-то сетевая поддержка в MS-DOS все-таки есть, в частности она может монтировать сетевые диски Novell Netware, которые замечательно видит doswin32);
q поддержки NTFS (наверное, это самый больной вопрос, препятствующий использованию doswin32 как системной дискетки для "починки" упавшей NT, тем не менее мы можем использовать NTFS-драйвера от сторонних производителей, подробнее о которых рассказывается в моей книге "Техника восстановления данных", к тому есть надежда "примерить" NTFS-for-DOS Мрака Руссиновича и doswin32, чем Харон сейчас и занимается);
q графической и оконной подсистемы (функции user32.dll и gdi32.dll не реализованы и доступен лишь текстовой режим)
Таким образом, doswin32 позволяет запускать не сильно извращенные консольные программы, к которым помимо FAR'а относятся компиляторы, линкеры, отладчики типа Turbo Debugger и прочий инструментарий. А настоящему программисту ничего другого для счастья и не нужно! Шутка. На самом деле никто не предлагает устанавливать doswin32 на устаревшее оборудование только затем, чтобы программировать под него (хотя, если вы стеснены в средствах, то… почему бы и нет?). Вместо этого мы будем программировать для него! Для устаревшего оборудования в смысле, которое можно использовать и как "фундамент" встраиваемых систем реального времени, и как рабочие станции "тонких" клиентов, и еще как черте что.На периферии сплошь и рядом стоит MS-DOS, под которую постоянно простят что-то написать/дописать, но не возвращаться же ради этого в давно забытый, похороненный и заброшенный Turbo Pascal?! Конечно же нет! Достаточно написать консольное win32-приложение (при желании и под Turbo Vision), использующее "плоскую" модель память и кучу готовых библиотек, откомпилировать его своим любимым компилятором и… запустить в MS-DOS с помощью doswin32!
Рисунок 2 FAR, запущенный из чистой MS-DOS под doswin32, свободно умещающийся на одной системной дискетке
