Как запускать UNIX приложения под Windows 1 страница

Ø В этой главе:

Ø Отличия между UNIX и Windows

Ø Перенос приложений с UNIX на Windows

Ø Техника эмуляции UNIX

Ø Различия между дескриптором и обработчиком

Ø Различия в реализации процессов в UNIX и Windows

Ø Имитация вызовов fork и exec

Ø Эмуляция сигналов

Ø Отличия в реализации кучи

Ø Различие наклона черты-разделителя каталогов

Ø Наименования стандартных устройств в UNIX и Windows

Ø Имитация чувствительности к регистру в наименовании файлов

Ø Отсутствие поддержки сырых гнезд в Windows

Ø Сравнение эмуляторов UWIN и CYGWIN

"...ты выбрал самый трудный путь для того, чтобы взобраться сюда. Иди за мной, я покажу тебе самый легкий путь"

Френк Херберт "Дюна"

Открытость исходных текстов большинства UNIX-приложений чрезвычайно облегчает их анализ на предмет поиска дыр, – разве можно сравнить это с утомительным дизассемблированием кода Windows NT?

Однако простой визуальный просмотр распечаток – крайне неэффективный и трудоемкий метод исследования. Разумнее установить на компьютере UNIX и прогонять код под отладчиком. В любом случае UNIX потребуется для получения навыков работы с командными оболочками. Позже это пригодится для удаленного запуска программ и управления своим акаунтом на сервере.

Современные версии UNIX снабжены достаточно грамотными программами инсталляции, и в большинстве случаев установка никаких проблем не вызывает. Но… может «скушать» до пятисот мегабайт дискового пространства, и уж наверняка потребует перекройки таблицы разделов, – а гарантировать сохранность информации разработчики, естественно, не собираются. Резервироваться? Уж лучше купить новый жесткий диск!

Но можно пойти и другим путем – воспользоваться утилитами, позволяющими запускать UNIX приложения прямо из-под Windows! Написать полноценный эмулятор UNIX теоретически возможно, правда, вряд ли кому-то удастся добиться хорошей производительности. Да и зачем? Исходные тексты большинства приложений доступны, – остается перекомпилировать их под новую платформу и все! Но на самом деле это далеко не так просто, как может показаться на первый взгляд. Архитектуры UNIX и Windows в целом очень близки, но незначительные отличия не позволяют запустить «чужой» код без существенной переработки программы.

Поэтому, приходится выкручиваться иначе, – добавлять к Windows еще одну библиотеку, сглаживающую различия системных функций обоих операционных систем. Именно так и поступил Дэвид Корн (автор известной одноименной оболочки), создатель UWIN.

На рисунке 041 на первый взгляд изображен знаменитый “Norton Commander” но, присмотревшись внимательнее, можно различить «неправильный»[78] символ-разделитель каталогов. Да, это “Midnight Commander”, - Norton для UNIX.

Рисунок 041.bmp Так выглядит Midnight Commander, запушенный на эмуляторе UNIX в среде Windows 98

Стоит развернуть окно консоли на полный экран, и не каждый поклонник UNIX разберется в какой операционной системе он работает! Конечно, «живая» UNIX все же лучше, но для большинства задач, описываемых в книге, эмулятор вполне подойдет.

Разумеется, UWIN не единственное приложение в своем роде. Существует еще CYGWIN, NUTCRACKER и множество других аналогичных программ. Какую из них использовать – выбирать читателю, но в книге будут описаны лишь две – UWIN и CYGWIN. Для некоммерческого использования они бесплатны, остальные же требуют оплаты, зачастую превышающей стоимость фирменного диска UNIX и дополнительного винчестера!

Перед углублением в описание особенностей обоих программ полезно рассмотреть: в чем заключатся различия между Windows и UNIX, и какие существуют пути их преодоления. «С высоты птичьего полета» эти операционные системы практически идентичны друг другу, и если бы программисты не использовали особенностей реализации той или иной функции в переносе прикладных приложений никаких проблем не возникало[79].

Так, в UNIX каждый открытый файл ассоциирован с дескриптором, а Windows используют HANDLE[80]. В первом приближении одно идентично другому – это «магические» числа, интерпретировать которые может только операционная система, а для приложений они представляется «черными ящиками». Сказанное справедливо для Windows, но в UNIX[81] дескрипторы упорядочены и предсказуемы. Напротив, HANDLE представляют собой случайные 32-числа, поэтому программы, написанные с учетом особенностей представления дескрипторов UNIX, откажутся работать в Windows. Возможный выход из такой ситуации заключается в создании собственной таблицы обработчиков, идентичной для всех процессов и хранящей упорядоченный список дескрипторов (смотри рисунок 001.txt).

Рисунок 001.txt Создание эмулятором собственной таблицы файловых манипуляторов

Причем, один и тот же дескриптор может ассоциироваться с несколькими HANDLE. Например, оба дескриптора консоли, одновременно открытой как на запись, так и на чтение должны управляться всего одним обработчиком. Это обстоятельство крайне важно, ибо в Windows не существует глобальной таблицы обработчиков общей для всех процессов[82]. Каждый процесс имеет собственную локальную таблицу, поэтому бессмысленно пытаться использовать HANDLE чужого процесса. Локализация манипуляторов значительно повышает надежность системы, но затрудняет межпроцессорные взаимодействия, и все UNIX приложения, не рассчитывающие на такой поворот событий, тут же откажут в работе. Поэтому, необходимо собрать все HANDLE в одну таблицу, общую для всех UNIX-процессов (смотри рисунок 002.txt).

Рисунок 002.txt (показаны локальные таблицы HANDLE для двух Windows-процессов, и их отображение в глобальную таблицу дескрипторов UNIX-эмулятора)

Намного более существенны различия реализаций процессов в UNIX и Windows. Поддержка многозадачности в UNIX реализована крайне убого (да не обидятся ее поклонники на это высказывание). Системный вызов exec, запуская новый процесс, «подминает» текущий, поэтому, до запуска exec обычно используется функция fork, расщепляющая один процесс на два – родительский и дочерний. Процесс-сын наследует все открытые файлы отца, сегмент данных и продолжает выполнение с той же самой точки, в которой завершился вызов fork. Отличие между ними заключается лишь в возвращаемом функцией fork значении. Родительский процесс получает идентификатор дочернего, а сам дочерний всегда ноль. Поэтому, код, поражающий новый процесс, в UNIX приложениях обычно выглядит так: “if (fork()==0) exec(“/bin/vi”,”/etc/passwd”,0);”.

В Windows все намного естественнее и элегантнее. Вызов CreateProcess действительно порождает новый процесс, не затирая текущий. При этом сохраняется возможность наследования всех обработчиков установкой флага bInheritHandles. Поэтому, функция CreateProcess практически эквивалентна последовательным вызовам fork + exec. Но аналога fork в Windows нет, как нет возможности расщепления процессов! По большому счету это просто не нужно современным программистам, но часто использовалось разработчиками UNIX-приложений.

Любой эмулятор UNIX должен уметь имитировать вызов fork, благо гибкая архитектура Windows это позволяет. Чаще всего создается приостановленный (suspend) процесс с той же самой стартовой информацией, что и текущий. До выполнения функции main() из родительского процесса в дочерний копируется сегмент данных, стек и дублируются все обработчики. В последнюю очередь модифицируется контекст процесса, хранящий значения регистров, в том числе и регистра указателя очередной выполняемой команды (в 386+ серии микропроцессоров он носит название EIP).

Гораздо проще имитировать exec, – достаточно вызвать CreateProcess и “прибить” текущий процесс, имитируя его замещение новым. Остается всего лишь переустановить идентификатор, сохраняя генеалогическую линию. Если этого не сделать, вновь порожденный процесс станет потомком процесса, вызвавшего exec, а в оригинальной системе UNIX функция.exec не создает дочернего процесса и сохраняет идентификатор текущего. Но идентификатор процесса выдается операционной системой и не может быть изменен по желанию приложения! Другими словами, если “Процесс 0” породил “Процесс 1” и запомнил его идентификатор, а “Процесс 1”, имитируя вызов exec, обратился к функции CreateProcess и вызвал exit для завершения своей работы, то “Процесс 0” будет по-прежнему ссылаться на уже несуществующий “Процесс 1”, ничего не зная о порожденном “Процессе 2”, обладающего иным идентификатором.

Ситуация разрешается созданием собственной таблицы идентификаторов эмулятором UNIX. Родительский процесс в качестве идентификатора получает индекс ячейки такой таблицы, содержащей настоящий идентификатор дочернего процесса. В результате появляется возможность «подменить» идентификатор «Процесса 1» на «Процесс 2» незаметно для родительского процесса. (Смотри рисунок 003.txt)

Рисунок 003.txt Имитация эмулятором системного вызова fork

В отличие от Windows, UNIX поддерживает сигналы – удобное средство межпроцессорного взаимодействия, своеобразный аналог программно-аппаратных прерываний. Механизм же сообщений, реализуемый Windows, требует постоянного опроса очереди сообщений на предмет обнаружения новых поступлений. Так, например, при закрытии окна приложению посылается сообщение WM_CLOSE, но если оно в этот момент не читает очередь, а занято чем-то другим, скажем, форматированием очередного трека дискеты или сортировкой данных, то проигнорирует попытку закрытия, и продолжит работу вплоть до следующей проверки очереди. Поэтому, практически в каждом Windows-приложении присутствует следующий код:

· while (GetMessage (&msg, NULL, 0, 0))

· {

· TranslateMessage (&msg);

· DispatchMessage (&msg);

· }

Исключения составляют консольные приложения, а во всех остальных случаях никакое однопоточное приложение не может «забыть» о проверке очереди сообщений больше чем на десятую долю секунды, не вызывая протестов со стороны пользователя, ругающегося ни на что не реагирующую программу.

В UNIX все гораздо проще – операционная система автоматически прерывает работу процесса-получателя и передают управление на подпрограмму обработки сигнала, а после ее завершения возобновляет выполнение прерванного процесса с того же самого места.

К счастью, в Windows 9x/Winwos NT существует многопоточность и множество механизмов межпроцессорных взаимодействий, поэтому имитировать поддержку сигналов вполне реально. Для этого в каждом эмулируемом приложении необходимо выделить отдельный поток, ожидающий ну, например, события (Event) и передающий управление на соответствующую подпрограмму при его наступлении. (Смотри рисунок 004.txt) События выгодно отличаются возможностью «заморозить» ожидающий поток, не теряя впустую драгоценного процессорного времени.

Следует отметить, функция “kill” вовсе не убивает процесс, как это следует из ее названия, а отправляет ему сигнал, который тот может либо проигнорировать, либо обработать по своему усмотрению.

Рисунок 004.txt Имитация эмулятором механизма сообщений

Другое существенное отличие заключается в поведении кучи (heap) при изменении размеров выделенного блока. Куча – это динамически распределяемая область памяти. Не вникая в технические тонкости той или иной реализации, достаточно отметить три важнейшие операции, совершаемые над кучами – выделение блока памяти, освобождение и изменение его размеров. Первые две никаких проблем не вызывают, но вот динамическое изменение размера – штука интересная. Легко уменьшить размер блока, но намного чаще программистам требуется его увеличить (для того кучи и задуманы, чтобы сначала запросить немножечко памяти, а по мере потребности требовать ее все больше и больше). А как поступить, если к концу одного блока вплотную примыкает следующий? UNIX использует трансляцию адресов, то есть определенным образом отображает физические адреса на логические, создавая видимость непрерывности всего блока памяти, хотя на самом деле он состоит из множества беспорядочно разбросанных фрагментов. А вот Windows находит подходящий по размеру свободный блок памяти, проецирует в его начало содержимое увеличиваемого блока и возвращает новый указатель начала блока. Программы Windows, рассчитанные на такое поведение, выполняются успешно, но вот, попробуй-ка, научи UNIX-приложения этим фокусам! Поэтому, эмулятор UNIX должен иметь свой собственный менеджер куч, работающий с памятью Windows на низком уровне функциями VirtualAlloc и VirtualFree.

Описанные выше различия относятся к тонкостям реализации, и скрыты от простого пользователя, отличающего Windows от UNIX по наклону черты-разделителя. Совершенно непонятно, почему разработчики MS-DOS вопреки всем соглашениям де-факто, решили проявить оригинальность, применив не прямой, а обратный слеш, зарезервированный в Си для управляющих символов. Очевидно, перенос программы из UNIX в MS-DOS (Windows) потребовал бы переделок значительной части кода и существенных усилий. К счастью, эмуляторы позволяют этого избежать, автоматически переформатировав строку (в простейшем случае) или установив новый драйвер файловой системы (для обеспечения полной имитации). Не следует забывать, файловая система в UNIX монтируемая, т.е. объединяет в одну логическую структуру файлы и каталоги, физически расположенные не только на разных носителях, но и компьютерах.

Гораздо больше неудобств доставляет «двойной» перенос строки в MS-DOS (Windows), задаваемый символами “\r\n”, тогда как UNIX ожидает лишь одиночного символа “\n”. Поэтому, в большинстве случаев UNIX-приложения не могут корректно обрабатывать тексты, созданные редакторами MS-DOS (Windows) и наоборот. Так, текст программы, набранный в редакторе edit, вызовет протест со стороны UNIX-версии интерпретатора Perl.

Универсального выхода из этой ситуации не существует, но посредственных решений проблемы можно предложить сколько угодно. Чаще всего эмуляторы при открытии файла в текстовом режиме самостоятельно обрабатывают символы перевода строки, следуя UNIX-соглашению. Файл, открытый в двоичном режиме читается «как есть», поскольку невозможно различить действительный перевод строки от совпадения последовательности символов. К сожалению, многие приложения обрабатывают текстовые файлы, открывая их в бинарном режиме. Поэтому, лучше всего переносить файлы данных вручную, при необходимости заменяя символы переноса строки.

Точно так, в MS-DOS и UNIX не совпадают наименования устройств. Например, для подавления вывода сообщений на экран в MS-DOS используется конструкция “>nul” (“echo Это сообщение никогда не появится на экране >nul”), а в UNIX – “>/dev/null” (“echo Это сообщение никогда не появится на экране > /dev/null”). Другие примеры различий показаны в таблице 1

Устройство	Название в UNIX	Название в MS-DOS
Консоль	/dev/tty	Con
Стандартный ввод	/dev/stdin	Con
Стандартный вывод	/dev/stdout	Con
Черная дыра	/dev/null	Nul
Привод гибких дисков	/dev/fd	А: (B:)
Параллельный порт	/dev/lp	Com
Последовательный порт	/dev/mod	lpt

Таблица 1 Различия наименования устройств в UNIX и MS-DOS

Поэтому, любой эмулятор должен предоставлять собственную библиотеку функций для работы с файлами, имитирующую наличие указанных устройств. Это реализуется простым преобразованием имен и контролем доступа операций записи и чтения (например, в стандартный ввод нельзя записывать, хотя MS-DOS это позволяет, совмещая и ввод, и вывод в одном устройстве под названием ‘con’ – сокращение от console).

К сожалению, существуют и такие различия, сгладить которые невероятно трудно. Так, например, система UNIX чувствительна к регистру в именах файлов и допускает мирное сосуществование “myfile” и “MyFile” в одном каталоге. Кажется, единственный способ приучить к этому Windows, – реализовать собственную файловую систему, но существуют более простые, хотя и менее элегантные решения. Некоторые эмуляторы ассоциируют файлы с таблицами виртуальных имен, обрабатываемых по правилам UNIX. (Смотри рисунок 005.txt)

Рисунок 005.txt Создание эмулятором таблицы виртуальных имен, чувствительных к регистру

Намного хуже дело обстоит с поддержкой сырых гнезд (SOCK_RAW). Если говорить просто, сырые гнезда позволяют прикладной программе самостоятельно сформировать заголовок IP пакета, – действие редко используемое в нормальной жизни, но необходимое для множества атак.

Спецификация WINSOCK 2.x как будто бы подтверждает их наличие в Windows, но на самом деле, соответствующие функции реализованы неправильно и посылают подложный пакет, помещая пользовательский заголовок в область данных. Не то чтобы ситуация была полностью безнадежна, но написание собственных драйверов TCP/IP требует надлежащей квалификации разработчиков, и ни один из известных автору эмуляторов сырых гнезд не поддерживает.

К слову сказать, помимо гнезд семейства AF_INET, в UNIX существуют и гнезда используемые для межпроцессорного взаимодействия, не поддерживаемые WINSOCK, но реализуемые подавляющим большинством эмуляторов.

Рассмотрев теоретические различия между UNIX и Windows, перейдем к сравнению конкретных реализаций эмуляторов. Для этого возьмем двух ярких представителей, UWIN от компании AT&T (кто знает UNIX лучше AT&T?) и CYGWIN, поддерживаемый в рамках проекта GNU[83].

Рисунок UWIN.GIF Логотип эмулятора UWIN

Для некоммерческого использования полноценную копию UWIN можно получить бесплатно, посетив сайт автора – http://www.research.att.com/sw/tools/uwin/. Установленный UWIN предоставляет следующие возможности: “ UWIN has a set of popular shells like ksh (Kornshell) & tcsh (C shell) and more than 300 utilities like vi, ls, ps, grep, tail, uudecode/uuendecode, mailx, find, perl, awk, etc along with a vt100 terminal emulation. It also provides a Telnet server along with other inet daemons and utilities like telnet, ftp, rsh, rlogin, and their corresponding servers for Windows NT, enabling a user to remotely access the system over the network. Optional tools include the Apache Web-server and bind DNS server. [84] ”

Врезка «Системные требования UWIN»*

· Software requirements Software requirements

· UWIN Base toolkit + UWIN SDK

· Microsoft Visual C/C++ 4.0 or higher or GNU C/C++ compiler

· Microsoft Windows NT 4.0 or higher (Workstation or Server) or

· Microsoft Windows 95/98

· Hardware requirements Hardware requirements

· Intel x86, Pentium, Pentium Pro and compatible systems

· 30-100MB of available hard-disk space

UWIN содержит множество популярных командных оболочек, свыше 300 необходимых для работы утилит и даже позволяет запускать Apache WEB сервер и DNS сервер. Администраторов Windows NT не может не порадовать наличие полноценного telnetd –демона (как известно в штатную поставку Windows NT не входит никаких средств удаленного управления компьютером)[85].

Рисунок 048 Демонстрация наличия telnet-сервера в эмуляторе UWIN

Разработчикам пригодится компилятор GNU C/C++ и отладчик gdb, или любой другой инструментарий – по выбору. Например, perl, awk, tcl.. да всего не перечислишь! Кстати, в UWIN входит «обертка» (wrapper) для Microsoft Visual C++, дополняющая его возможностью обработки исходных текстов UNIX-приложений. Разумеется, откомпилированный текст можно отлаживать чем угодно, в том числе и Soft-Ice, не имеющим аналогов в среде UNIX.

Наконец, даже никого не собирающиеся атаковать пользователи, со временем обнаружат – пользоваться командными оболочками UNIX, намного удобнее, чем елозить мышью. Благо, UWIN позволяет запускать не только UNIX, но и Windows-приложения, умело обращаясь не только с дисками, но и с реестром.

Отныне ветви реестра будут представлены каталогами, а ключи – файлами. Корневой раздел реестра монтируется в каталог “/reg” На рисунке 049 показано, как вывести на экран содержимое ветви реестра “HKEY_CURRENT_USER\Network\Persistent\H”. Но этим возможности UWIN не ограничиваются. В реестре становится возможным хранить и обрабатывать файлы, точь-в-точь как на обычном жестком диске!

Рисунок 049.bmp Эмулятор UWIN позволяет обращаться с реестром Windows точно так, как с файлом

Выше был употреблен термин “монтируется” – UWIN эмулирует монтируемую файловую систему, то есть позволяет произвольным образом объединять в одну логическую структуру, файлы и каталоги физически расположенные на разных дисках и даже компьютерах. По умолчанию корневым каталогом назначается директория, в которую инсталлирован UWIN. Корень диска «С» становится каталогом “/C/”, и соответственно “/A/”, “/B/”, “/D/”, “/E” для остальных дисков (если они есть). Каталог Windows доступен как “/C/Windows”, так и через короткий псевдоним “/Win”. Сетевые компьютеры автоматически монтируются так же, как и в Windows, но с наклоном черты в обратную сторону, т.е. “\\SERVER\C” станет называться “//SERVER/C”. Вообще же узнать, как смонтирован тот или иной ресурс можно с помощью команды mount. Например, на компьютере автора результат ее работы выглядел так:

· C:\Program Files\UWIN on / type FAT32 (ic,text,grpid,suid,rw)

· C:\Program Files\Microsoft Visual Studio\vc98\ on /msdev type FAT32 (ic,text,grpid,suid,rw)

· A: on /A type FAT (ic,text,grpid,suid,rw)

· C: on /C type FAT32 (ic,text,grpid,suid,rw)

· D: on /D type FAT32 (ic,text,grpid,suid,rw)

· E: on /E type FAT32 (ic,text,grpid,suid,rw)

· F: on /F type FAT32 (ic,text,grpid,suid,rw)

· //SERVER/C on /H type FAT ()

· /usr/bin on /bin type LOFS (ic,text,grpid,suid,rw)

· /usr/lib on /lib type LOFS (ic,text,grpid,suid,rw)

· /usr/etc on /etc type LOFS (ic,text,grpid,suid,rw)

· /usr/dev on /dev type LOFS (ic,text,grpid,suid,rw)

· /C/WINDOWS on /win type FAT32 (ic,text,grpid,suid,rw)

· /C/WINDOWS/SYSTEM on /sys type FAT32 (ic,text,grpid,suid,rw)

· /usr/proc on /proc type PROC (ic,text,grpid,suid,rw)

· /usr/reg on /reg type REG (ic,text,grpid,suid,noexec,rw)

Однако, монтируемая файловая система видна только из-под UWIN, а Windows-приложения даже и не подозревают о ней. Поэтому, попытка вызвать notepad для просмотра фала /win/readme.txt провалится, а правильный вариант должен выглядеть так: “/win/notepad C:\\windows\\readme.txt”. Дублирование косой черты обязательно, в противном случае Windows сообщит: “Не удается найти файл C:windowsreadme.txt” (такая ситуация показана на рисунке 050):

Рисунок 050 Демонстрация вызова приложений Windows из эмулятора UNIX

Так происходит потому, что в UNIX (и UWIN), косая черта “\” зарезервирована за управляющими символами (например, “\t” обозначает знак табуляции, а “\n” – перенос строки), а когда требуется отобразить сам символ обратной черты, прибегают к его дублированию.

Каталог “/dev” предназначен для управления устройствами. Его содержимое может быть следующим:

· $ ls /dev

· clipboard ptyp0 ptyq7 tty06 tty29 ttypb

· fd ptyp1 ptyq8 tty07 tty30 ttypc

· fd0 ptyp2 ptyq9 tty08 tty31 ttypd

· fd1 ptyp3 ptyqa tty09 tty32 ttype

· lp ptyp4 ptyqb tty10 tty33 ttypf

· lp0 ptyp5 ptyqc tty11 tty34 ttyq0

· lp1 ptyp6 ptyqd tty12 tty35 ttyq1

· lp2 ptyp7 ptyqe tty13 tty36 ttyq2

· mod0 ptyp8 ptyqf tty14 tty37 ttyq3

· mod1 ptyp9 rmt0 tty15 tty38 ttyq4

· mod2 ptypa rmt0n tty16 tty39 ttyq5

· mod3 ptypb rmt1 tty17 tty40 ttyq6

· mod4 ptypc rmt1n tty18 ttyp0 ttyq7

· mod5 ptypd stderr tty19 ttyp1 ttyq8

· mod6 ptype stdin tty20 ttyp2 ttyq9

· mod7 ptypf stdout tty21 ttyp3 ttyqa

· mt0 ptyq0 tty tty22 ttyp4 ttyqb

· mt0n ptyq1 tty00 tty23 ttyp5 ttyqc

· mt1 ptyq2 tty01 tty24 ttyp6 ttyqd

· mt1n ptyq3 tty02 tty25 ttyp7 ttyqe

· null ptyq4 tty03 tty26 ttyp8 ttyqf

· ptmx ptyq5 tty04 tty27 ttyp9 windows

· ptymx ptyq6 tty05 tty28 ttypa

Под незамысловатым именем clipboard скрывается буфер обмена Windows. С помощью UWIN из него можно читать и писать как в обычный файл; “fd” – обозначают приводы гибких дисков, прежде чем с ними начать работать необходимо воспользоваться командой mount; “lp” символизирует параллельный порт, и для вывода файла на принтер достаточно скопировать его в устройство “lp1” (LPT1) или “lp2” (LPT 2) в зависимости от схемы подключения (“cp myfile lp1”). Последовательный (т.е. COM) порт, обозначается как “mod” и может использоваться для управления модемом (например “echo atz\natdp 02 > mod1”); “mt” расшифровывается как SCSI Type Driver[86] и всегда присутствует в списке устройств, даже когда на компьютере не установлено ни одного SCSI контроллера. Назначения остальных устройств можно узнать из прилагаемой к UWIN документации.

Описание UWIN останется не полным, если не снять с него крышку, и не заглянуть под капот. Архитектурно эмулятор состоит всего из двух динамических библиотек POSIX.DLL и AST5x.DLL. В POSIX реализовано множество системных вызовов UNIX таких, как fork, exec, malloc; фактически образующих ядро виртуальной UNIX. Ядро заведует памятью, управляет процессами и отвечает за операции ввода-вывода. Роль AST5x гораздо скромнее – это всего лишь аналог стандартной библиотеки Си “stdio”, написанной с учетом особенностей эмуляции UNIX. (Смотри рисунок 042)

Рисунок 042 Архитектура эмулятора UWIN

При этом все UWIN-приложения разделяют общий регион памяти, содержащий в частности таблицу открытых файлов и кучу. («UWIN maintains an open file table in a memory-mapped region, which is shared by all the currently active UWIN processes; this region is writable by all UWIN processes so that the appropriate information can be shared between them»). (Смотри рисунок 006.txt) Отсюда следует, одно UWIN приложение потенциально способно «уронить» другое, или иными словами, некорректно работающий код может скинуть ласты, предоставив злоумышленнику привилегированный доступ к системе. Поэтому, если UWIN используется в качестве серверной платформы, не следует запускать приложения сомнительного происхождения.

Рисунок 006.txt Разделяемая память UWIN-приложений

В остальном же, UWIN приложения ничем не отличаются от обычных исполняемых файлов Windows и могут запускаться непосредственно из Explorer, минуя среду UIWN.

Рисунок cygwin.bmp Логотип CYGWIN

Другой популярный эмулятор UINX – CYGWIN по многим показателям заметно уступает UWIN, зато распространяется вместе с исходными текстами и, разумеется, абсолютно бесплатен. Зато плохо документирован и рассчитан на опытного пользователя, который сам разберется что к чему.

Собственно, CYGWIN никакой не эмулятор UNIX, а всего лишь набор функций, помещенных в одну динамическую библиотеку “cygwin1.dll” и облегчающий перенос UNIX-приложений в среду Windows,. Для получения навыков работы в командных оболочках он, конечно, сгодится, но для изучения тонкостей UNIX – навряд ли. Для подтверждения этого ниже приведены результаты работы команды “cat /etc/passwd[87]” в UWIN и CYGWIN:

Дата добавления: 2015-11-14