· 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. Разделяемая память UWIN-приложений
В остальном же, UWIN приложения ничем не отличаются от обычных исполняемых файлов Windows и могут запускаться непосредственно из Explorer, минуя среду UIWN.
Логотип CYGWIN
Другой популярный эмулятор UINX - CYGWIN по многим показателям заметно уступает UWIN, зато распространяется вместе с исходными текстами и, разумеется, абсолютно бесплатен. Зато плохо документирован и рассчитан на опытного пользователя, который сам разберется что к чему.
Собственно, CYGWIN никакой не эмулятор UNIX, а всего лишь набор функций, помещенных в одну динамическую библиотеку “cygwin1.dll” и облегчающий перенос UNIX-приложений в среду Windows,. Для получения навыков работы в командных оболочках он, конечно, сгодится, но для изучения тонкостей UNIX - навряд ли. Для подтверждения этого ниже приведены результаты работы команды “cat /etc/passwd [87]” в UWIN и CYGWIN:
· UWIN
· $ cat /etc/passwd
· root:x:0:13:Built-in account/domain:/tmp:/usr/bin/ksh
· telnetd:x:1:1:telnetd:/:/dev/null
· CYGWIN
· $ cat /etc/passwd
· /etc/passwd: No such file or directory
В CYGWIN вообще нет файла “/etc/passwd” и он не эмулирует подсистему безопасности UNIX. Конечно, это не мешает написать соответствующие процедуры самостоятельно, но не лучше ли воспользоваться готовым UWIN? Кстати, в UWIN изначально входит базовый набор утилит и оболочек, автоматически устанавливаемых программой инсталляции. Напротив же, пользователи CYGWIN вынуждены самостоятельно скачивать необходимые компоненты с сервера, порой исправляя грубые ошибки, часто приводящие к полной неработоспособности кода (благо исходные тексты доступны).
Больше всего огорчает отсутствие в CYGWIN механизма поддержки демонов. Так, на момент написания книги, не известно ни одной реализации telnet-сервера под CYGWIN. В остальном же архитектуры этих двух эмуляторов достаточно близки. Как и в UWIN используется разделяемая память для всех приложений ("…creates shared memory areas… used to keep track of open file descriptors and assist fork and exec, among other purposes" [88]). Реализация fork сводится к созданию приостановленного процесса с последующим копированием сегмента данных ("…creates a suspended child process using the Win32 CreateProcess call; next… fills in the child's.data and.bss sections by copying from its own address space into the suspended child's address space”). А выполнение exec приводит к образованию нового процесса и подмене идентификаторов в локальной таблице эмулятора -"…exec present their own set of difficulties. Because there is no way to do an actual exec under Win32, Cygwin has to invent its own Process IDs"