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

Прежде всего, зададимся вопросом, а надо ли вообще переносить программы, например, из среды Unix в NT? Битва между этими операционными системами в самом разгаре, NT-серверы завоевывают все большее рыночное пространство. Windows NT постепенно становится более масштабируемой, появилась поддержка больших массивов данных, получает распространение мнение об относительной дешевизне поддержки этой ОС. При этом ряд критически важных задач по-прежнему остаются в сфере влияния Unix.

По данным Forrester Research, в период между 1998 и 2000 годами NT-серверы соберут с рынка «урожай» в 49 млрд. долл. (2,8 млн. единиц оборудования), тогда как на долю Unix придется 52 млрд. долл. (1,4 млн. единиц). Кроме того, большинство крупных компаний планирует совместно использовать оба типа ОС. По данным IDC, ежегодный рост продаж лицензий на Windows NT Server до 2002 года будет составлять 23%, сравните с 11% для Unix и 7% для Novell NetWare (здесь в категорию Unix включены Sun Solaris, HP-UX, IBM AIX, Tru64 Unix, SCO OpenServer и SCO UnixWare). Так или иначе, большая часть компаний планирует увеличить в своем компьютерном парке машин долю NT-серверов, в значительной мере за счет сокращения доли Novell.

Иными словами, неизбежно мирное сосуществование двух операционных систем. В ближайшее десятилетие предприятия будут вкладывать средства как в платформы Unix, так и в Windows, обеспечивая в ряде случаев их совместную работу.

Однако обе операционные системы имеют существенные различия как на уровне приложений, оборудования, так и менталитета работающего с ними персонала. Простого объединения двух систем, скажем, через TCP/IP недостаточно, совместная работа - это общее системное администрирование, обеспечение конфиденциальности, совместное использование приложений, файлов, организация печати, интеграция протоколов и т.п. Некоторые их этих аспектов могут решаться для гетерогенных систем в рамках специализированного ПО управления системами, например, CA-Unicenter TNG, HP OpenView, IBM Tivoli. Получила также развитие технология промежуточного ПО, ориентированного, в частности, на организацию доступа Windows-клиентов к Unix-серверам или мэйнфреймам. Одно из возможных решений на этом пути — в эмуляции VT- или X-терминалов, что позволяет получить необходимую функциональность. Однако доступ к файлам приложений или организация печати со всех точек и на любых уровнях часто превращается в серьезную проблему. Две ОС слишком различны, чтобы существовать вместе без хлопот: либо NT придется нести бремя выполнения NFS, либо Unix — выполнять SMB.

Можно выделить четыре современных подхода к организации совместной работы Windows NT и Unix.

Интеграция платформ путем выполнения приложений в архитектуре клиент-сервер. При этом задача запускается на одной платформе, а управление и обработка результатов происходят на другой. Возможный инструментарий - X-сервер, который способен поддержать доступ к задачам из различных вариантов Unix, OpenVMS, к суперкомпьютерным приложениям, а также выводить результаты в среде NT. Другой пример воплощения подобного подхода - сетевая файловая система NFS (Network File System), позволяющая интегрировать файлы, находящиеся на различных компьютерах, в том числе и расположенные на Unix-платформах, с сохранением обычного способа доступа (например, через File Manager).

Эмуляция путем создания целевой среды, которая «понимала» бы системные вызовы исходной среды и преобразовывала их в соответствующие вызовы целевой среды. В качестве примеров реализаций Unix-подсистемы в NT можно назвать Intrix (компания Softway Systems), VP/ix (Interactive Systems), DOS Merge (Locus), WABI (SunSoft), SoftWindows (Insignia Solutions) и др.

Мобильные библиотеки, устанавливающие единый программный интерфейс на различных платформах с заменой системных вызовов. Это автоматически обеспечивает компоновку программного обеспечения на любой платформе при помощи соответствующей версии библиотеки. Однако подобный способ имеет ряд недостатков: большинство библиотек неполны и не успевают за появляющимися в ОС новшествами, а разработчики ПО оказываются привязанными к одному поставщику. Обычно такой подход практикуется для конкретных приложений: машинная графика, САПР.

Программы, предоставляющие API-интерфейсы Unix для Windows и позволяющие транслировать написанный для Unix код в код для NT, а затем использовать «родные» для NT компиляторы. Обычно эти средства интегрируют в себя некоторые черты Unix, такие как демон telnet и X-сервер, командные оболочки. Если речь идет о корпоративных приложениях, срок эксплуатации которых исчисляется годами, а функциональная часть которых имеет размер от сотен тысяч до десятков миллионов строк кода постоянно подвергаемых изменениям, то данный подход становится большим подспорьем для облегчения процесса переноса из Unix в Windows NT с сохранением эффективности.

Постановка задачи

Одна из наиболее актуальных задач — обеспечение совместной работы произвольного числа компьютеров, принадлежащих к нескольким платформам. Именно при решении этой задачи возникло понятие метакомпьютинг [1], неоднородные кластерные системы, а также родились разного рода глобальные системы ([2], http://www.globus.org/; www.cs. virginia.edu/~legion).

Среди продуктов, позволяющих организовать работу кластера из нескольких компьютерных платформ можно упомянуть свободно распространяемую систему DQS. Перед коллективом, в который входил и автор, стояла задача развернуть эту систему для работы с компьютерным парком из RISC-серверов производства Convex, Hewlett-Packard и SGI, а также многих ПК, применяемых для решения вычислительных задач1.

Все бы хорошо: и DQS доступна в исходных текстах, и документация по этой системе имеется, и инсталляция на сервере Hewlett-Packard с ОС HP-UX прошла без проблем, однако версии для NT на момент начала работ не существовало. Кстати говоря, почти все свободно распространяемые и большинство коммерческих систем управления кластерами тщательно избегают упоминания о возможности своей работы на NT. А это означает, что за пределами кластера остаются многие рабочие места на платформе Wintel. Беда, возможно, небольшая, но, учитывая исследовательский характер работы, мы решили поработать над текстом, чтобы дать возможность пользователям ПК работать c мощными многопроцессорными RISC-серверами, отлаживая программы, готовя данные и запуская задачи со своих настольных ПК.

Однако скоро только сказка сказывается: DQS - это почти 2 Мбайт исходного кода на Си, и не просто кода, а кода достаточно специфичного, использующего особенности Unix-платформ (процессы, сокеты, сигналы). Даже с точки зрения самих разработчиков перенос системы для работы с NT требовал много времени и ресурсов.

Вот что отмечал, например, основной разработчик DQS Том Грин: «NT 4.0 не является сегодня достаточно стабильной системой, а для кластерной системы, объединяющей в себе много различных компьютеров, где, в силу самой специфики задачи, вероятность сбоя достаточно велика, этот фактор оказывается критическим. Для переноса таких программ как DQS требуются квалифицированные кадры, одновременно разбирающиеся в Unix, NT и в прикладной задаче». Среди технологических проблем переноса разработчики упоминали принципиальную привязку DQS к механизму сигналов, который в NT устроен совсем иначе, нежели в Unix.

Тем не менее, учитывая важность переноса программы в среду NT, разработчики DQS пошли по пути создания Java-прототипа, который теоретически способен работать на Windows 95/NT. Не следует думать, что разработчики DQS столь ленивы, не имеют в своей команде специалистов по NT, не следят за рынком и т.д. Отнюдь. Абсолютно аналогичная картина наблюдается и в других коллективах, например, в компании Codine, занимающейся коммерческим распространением модернизированной системы DQS: «Мы планируем версию для Windows NT, однако эта работа завершится не ранее чем через год».

Проблемы переноса

Перенос программ между различными клонами Unix, например Linux и SunOS, обычно не составляет труда - как правило, он заключается в изменении имен некоторых функций или коррекция параметров, имеющих разную семантику в разных операционных системах:


#if (defined(_UNICOS) || 
defined(__hpux) || defined(solaris) || defined(SOLARIS23) || 
defined(SOLARIS24)) pid=waitpid(-1,&status,WNOHANG);
#else
bzero((char *)& rusage,sizeof(rusage));
pid=wait3(&status,WNOHANG,
(struct rusage *) &rusage);
#endif

Однако при переносе в Windows NT не часто удается ограничиться только синтаксическими исправлениями. Так, программы, использующие fork() или сигналы, должны быть переписаны - аналогичных функций в Windows попросту нет. Перечислим лишь некоторые принципиальные отличия, учет которых при переносе программ вручную может стоить достаточно дорого.

Привилегии доступа. В NT предусмотрена сложная система поддержки конфиденциального доступа, основанная на списках прав доступа Access Control List (ACL) и, хотя в современные варианты Unix модель ACL включена, обеспечение преемственности выливается в достаточно сложную задачу. Для файловой системы NTFS вызов chmod() модифицирует DACL (Discretionary Access Control List), который не соответствует соглашениям о правах доступа в Unix. Если, например, выполнить chmod() с кодом 007 (права на чтение/запись/выполнение для всех пользователей), а затем опросить это значение посредством stat(), то оно окажется равным 777. В NT процесс не может присваивать себе различные идентификаторы без запроса на аутентификацию или соответствующего соединения клиент-сервер, поэтому полная семантика функций setuid()/setguid()/setegid() работает только в специальных случаях - такие функции способна вызывать лишь программа с правами администратора.

Файлы. Имена файлов в Win32 и POSIX имеют разный синтаксис («» и «/», использование заглавных и строчных символов) поэтому при переносе программ требуется предусмотреть трансляцию. В Win32 поддерживаются символические ссылки (symbolic link) только между файлами, смонтированными в локальной файловой системе NTFS, а в Windows 95 ссылки вообще не поддерживаются.

Поддержка POSIX. В реализации POSIX для Windows NT имеется ряд ограничений, вытекающих, в частности, из самой природы POSIX. Приложения могут запускать только другие приложения POSIX и не работают с приложениями DOS, OS/2, Win16 или Win32. Нельзя в POSIX обратиться к системным функциям Win32 API, нет доступа к DDE, OLE и отображаемым в памяти файлам. Загрузка динамических библиотек, а также организация доступа к сетевым службам и функциям в POSIX-совместимых программах весьма проблематична. Большинство утилит для работы с POSIX-подсистемой не включены в стандартную поставку NT и доступны лишь в Windows NT Resource Kit.

Сигналы. В Win32 нет поддержки технологии обмена сигналами между процессами — прямого аналога kill(). Кроме того, большинство ядерных операций Win32 невозможно прервать.

Сокеты. Здесь в целом между NT и Unix много общего. Однако Winsock инициализируется до момента вызова первой функции, работающей с сокетом, а вызов select() в Unix не соответствует Win32 API, где он работает только с указателем сокета.

Уже из этого далеко неполного перечисления видно - для успешного переноса программы одного желания мало, особенно в условиях ограниченных ресурсов. В результате, время и стоимость работ по «ручному» переносу из одной среды в другую могут быть весьма существенными. По сути дела, иногда приходится заново переписывать код. Выход - применение специальных инструментальных систем, предназначенных для преобразования исходного кода программы для ОС Unix в вид, пригодный для Windows.

Один раз пишешь - много раз используешь

На сегодняшний день имеется, по крайней мере, пять инструментальных средств переноса ПО между Unix и NT: NuTCRACKER; U/WIN; Cygwin32; Interix (OpenNT); Wind/U.

NuTCRACKER

ПО NuTCRACKER компании DataFocus (http://www.datafocus.com) представляет собой семейство многоплатформных программ обеспечения работы Unix-приложений корпоративного уровня в среде Windows 95/98/NT. Система реализует для платформы Windows все предусмотренные в Unix возможности по созданию распределенных приложений на языках C, С++ или Фортран, поддерживает механизм разделяемых библиотек и демонов; имеются средства переноса в среду Windows приложений на языках Кобол и Ада. Перенесенные в среду Win32 приложения работают в ней без какой-либо эмуляции или промежуточного ПО.

NuTCRACKER поддерживает 2500 API-интефейсов Unix, включая Unix 98: управление процессами и сигналы; библиотеки stdio, math, curses, string; нити и т.п.; межпроцессорное взаимодействие и работа с сетями (сокеты, разделяемая память, очереди сообщений, семафоры); графика (X11R6, Motif 1.2.5, OpenGL, XView); отображение файловых систем и соглашений об именах Unix на Win32; поддержка Unix-инструментария, включая ar, cc, cxx, ld, make, imake, gmake, tcsh и pdksh; telnet-клиенты и серверы; RPC. Возможно использование всех популярных команд, утилит и API-интерфейсов из Unix 98, а также функций, специфических для конкретных платформ: Solaris, HP-UX, AIX, Irix, Linux и т.п. Аппарат U/Direct предназначен для Web-приложений, работающих в Unix. Поддержка многоплатформности осуществляется путем запуска компонентов COM, вызываемых из любой среды программирования (Visual J++, Visual Basic или Visual C++), а также включаемых в документы на HTML или Active Server Pages. Это позволяет популярным Unix-инструментам наподобие whois легко мигрировать на платформу Windows с поддержкой компонентов COM.

Особую гордость разработчиков NuTCRACKER составляет поддержка технологий работы с нитями POSIX и эмуляция слоев Distributed Computing Environment. Поддержка DLL реализуется как статически, так и динамически путем загрузки вместе с COM, Visual Basic или ActiveX. Кроме того, имеется поддержка систем, не работающих в среде Win32 приложений POSIX, которые с помощью NuTCRACKER получают доступ к СУБД Oracle, Sybase, Informix, Microsoft SQL Server. И наоборот, можно сделать традиционные Unix-приложения более «Windows-подобными».

В состав базового комплекта продукта входят библиотеки DLL; сервер консоли поддержки Unix-стиля работы; инструментарий разработки SDK для переноса приложений: включаемые файлы и библиотеки (API-интерфейсы Unix 98, POSIX, 4.4BSD и ANSI C), оболочки и утилиты ksh, csh, cc, ld, make, gmake, imake, perl, awk, sed, truss, vi; интерактивная система помощи.

Стоимость NuTCRACKER SDK составляет 3495 долл. Для ознакомления со своим продуктом компания практикует бесплатную передачу на срок в 30 дней полного комплекта разработчика системы NuTCRACKER. Предусмотрены скидки для учебных и научных учреждений.

Согласно требованиям лицензии Embedded Technology License продукт, созданный при помощи NuTCRACKER может использоваться в коммерческих целях в составе других систем. Сегодня более 600 независимых разработчиков Unix-приложений пользуются этой возможностью.

U/WIN

U/WIN (http://www.research.att.com/sw/tools/uwin) - набор команд, библиотек и включаемых файлов, обеспечивающих Unix-подобную операционную среду при работе с Windows 95/NT. Среда U/WIN была создана Дэвидом Корном из AT&T Labs, автором знаменитого ksh. Сопровождение, документация и распространение пакета (иногда вместе с исходными текстами) осуществляет компания Wipro. Ряд утилит и команд были заимствованы из GNU.

В пакете поддерживается большинство интерфейсов X/Open rel. 4, библиотеки и шрифты X11R6, имеется эмуляция vt100 и библиотека работы с курсором. U/WIN поддерживает интерфейс с Winsock. В состав U/WIN входят команды cc и ld для адаптации с компилятором Visual C/C++.

Cygwin32

ПО Cygwin32 (http://www.cygnus.com/misc/gnu-win32) предназначено для переноса в среду Win32 приложений из Unix. Поддерживаются операционные системы Windows 95/98/NT. Проект был начат в 1995 году компанией Cygnus Solutions для решения задачи переноса инструментария GNU в среду Win32. (Компания создана в 1989 году для коммерческой поддержки и разработки новых услуг для GNU. Деятельность этой компании является одним из возможных ответов на вопрос, как зарабатывать на бесплатном ПО.)

Cygwin32 поддерживает библиотеки DLL с большинством типичных для ОС Unix системных процедур, соответствующих POSIX.1/90 (кроме setuid и mkfifo), все процедуры из ANSI C и ряд основных служб BSD и SVR4, включая сокеты. Учитывая многообразие клонов Unix и изменчивость спецификаций Windows, нелишними при выполнении проекта Cygwin32 оказались инструменты sh, make, файловые утилиты (ls и rm), текстовые утилиты (cat, tr), утилиты оболочки (еcho, date, uname), а кроме этого sed, awk, find, xargs, tar и gzip. Системные вызовы реализованы в рамках динамической библиотеки Cygwin.dll, включаемой в любое приложение Cygwin. При помощи данного инструментария можно создавать консольные или графические приложения Win32, обращаясь как к стандартному API-интерфейсу Microsoft Win32, так и к Cygwin API. С помощью утилит dlltool и windres можно формировать динамические библиотеки DLL и работать с файлами описания ресурсов *.res. С помощью Cygwin для работы в Windows NT были перенесены такие известные инструменты GNU, как gcc, gdb, gmake. В состав Cygwin32 входит:

  • клиентская библиотека X11R6, позволяющая переносить X-приложения на серверы Win32 X (например, xterm, ghostview, xfig и xconq);
  • редакторы xemacs и vim;
  • GNU-утилиты inet, позволяющие запускать демоны inetd как службы Windows NT, формируя стиль работы в сети, принятый в Unix, но через аутентификацию из NT;
  • поддержка KerbNet - защита от несанкционированного доступа Kerberos, а также CVS (Concurrent Version System);
  • библиотека ncurses;
  • ssh (secure shell) для клиента и сервера;
  • PERL 5;
  • bash, tcsh, ash и zsh;
  • Web-сервер Apache;
  • TCL/TK 8, tix, itcl.

В соответствии с лицензией GNU, проект Cygwin32 имеет открытый характер, поэтому все желающие могут получить исходные тексты и развивать функциональность системы по своему усмотрению, правда, без поддержки, которую обычно оказывают коммерческие системы наподобие NuTCRACKER.

Interix (OpenNT)

Система Interix (http://www.interix.com) позволяет интегрировать на одной машине операционные системы Solaris, HP-UX, AIX, SCO с Windows NT. Пользователь, находясь в среде Interix, может запускать популярные Windows-приложения одновременно с приложениями Unix. ПО Interix работает на платформах Windows NT 3.51 и Windows NT 4.0 на процессорах Intel и Alpha.

В компании Softway Systems, разработчике Interix, утверждают, что построила открытую систему, которая предоставляет полную функциональность, как для пользователей, так и для разработчиков. Идеологически Interix функционирует аналогично подсистеме Win32 - в качестве надстройки над ядром Windows NT kernel [3]. Однако Interix - не эмулятор, приложения компилируются непосредственно в вызовы функций ядра Windows NT. Для переноса программ в состав системы включена среда разработки, включающая инструментарий и библиотеки API-интерфейсов. Для компиляции предлагается использовать Visual C/C++. В состав Interix Software Development Kit входят стандартные инструменты разработки GNU (g++, gcc, g77, gmake, gdb), выполнен перенос компилятора GNAT Ada 95. Поддерживаются устройства /dev/tty, /dev/null и /dev/tape, а также псевдотерминалы и консоли. Среди оболочек в составе Interix имеются ksh, Tcsh и GNU BASH 2.01. Имеется NFS, а также стандартные для Unix средства telnet, rcp, ftp. Предусмотрены утилиты для работы над Web-приложениями. Поддерживается файловая система Samba.

Подсистемы и команды Interix соответствуют стандартам IEEE 1003.2-1992 и ISO/IEC 9945 спецификации POSIX.2. В состав поставки входит четыре подсистемы: Interix Workstation Lite - собственно ядро Interix, клиенты времени исполнения X11R5 и один сервер Telnet Interix Workstation, сервер X11R6 и Motif 1.2.4 Window Manager. Имеется поддержка OpenGL. В состав Interix Professional SDK входят ODBC-библиотеки, обеспечивающие доступ к универсальным СУБД.

Компания Portland Group (http://www.pgroup.com), известный производитель распараллеливающих компиляторов, объявила недавно о переносе своих продуктов (компиляторов и профайлеров Fortran, Cи и C++) на NT. Основным инструментом преобразования кода программ был именно Interix. Около 40% суперкомпьютеров списка Top100 используют продукты Portland, в качестве основного инструмента создания параллельных приложений.

Компания Softway Systems практикует бесплатное предоставление версии пакета на срок в 45 дней.

Wind/U - от Windows к Unix

Семейство программ Wind/U компании Bristol Technology (http://www.bristol.com7) предназначено для разработки универсального программного обеспечения, способного работать на многих платформах: Windows 95, Windows NT, Unix, OpenVMS и OS/390. Wind/U обеспечивает совместимость между Windows и Unix/Motif. Дополнительные пакеты позволяют создавать приложения для дорогостоящих платформ Unix и OS/390, используя для этого существенно более дешевые ПК.

Кроме того, имеется пакет Jprinter для разработчиков на Java. Система Tributary дает возможность разработчикам писать и отлаживать программный код для платформ OS/390 и Unix, работая на ПК с Visual C++.

Чем же все это закончилось?

В результате анализа имеющихся средств переноса, учитывая имеющиеся ресурсы, а также исследовательский характер работы по переносу кластерной системы DQS в среду Windows NT были выбраны две системы NuTCRACKER и Cygwin32.

Процесс переноса любой программы из Unix в NT предусматривает выполнение семи шагов.

  • Запись исходных текстов в файловую систему Windows.
  • Корректировка make-файлов, файлов заголовков и текстов.
  • Компиляция и сборка.
  • Фиксация ссылок.
  • Отладка.
  • Интеграция с Windows (если используются функции, не предусмотренные в Unix).
  • Распространение готового продукта (для коммерческих продуктов).

Первый шаг проблем не вызвал - к услугам программистов средства ftp, rcp, NFS или Samba (http://samba.anu.edu.au/samba), предназначенные для переноса текстов программ из файловой системы Unix в Windows. Все эти средства автоматически учитывают символы окончания строки LF или CR+LF. Если в Windows используется файловая система NTFS, то проблем с длинными именами файлов из Unix не будет - имеется совместимость. Единственно, файлы Makefile и makefile в одном каталоге NTFS не уживутся.

Порядок выполнения второго шага зависит от инструментария, используемого при работе в Windows (скажем, интегрированная среда с Visual C++ или командная строка). Например, для

NuTCRACRER имеется оболочка shell для Windows, полностью повторяющая среду Unix. По существу, для переноса надо либо использовать утилиту make из комплекта поставки пакета, либо взять nmake из Windows. В первом случае не требуется никаких изменений. Однако чаще, если уж переходить на Windows, то трудно отказаться от удобств, предоставляемых интегрированными средствами разработки Borland C++ или Visual C++. В этом случае подготовительной работы будет больше. Обычно в документации соответствующих систем NutCracrer или Cygwin32 рекомендуется начинать с работы в простом режиме командной строки, а потом, после накопления опыта работы с программами переноса, переходить на интегрированные системы.

В каждом пакете имеются свои файлы заголовков, содержащие описания служебных переменных, макросов вызовов процедур Unix - Windows, переназначения маршрутных имен нестандартных заголовков (например, /include/sys), переключателей для исключения фрагментов программ. Кроме этого, учитывая разнообразие клонов Unix, в этих файлах предусматриваются ветвления для выбора кодов или вызовов функций, отвечающих исходному тексту Linux, BSD, Solaris и т.п. В файлах должны быть описаны все прототипы функций, даже отсутствующие в стандартном ANSI Cи.

Процесс компиляции и сборки сводится к настройке параметров трансляции и формированию для приложения в Windows такой же среды, что и в Unix: структура каталогов, макропеременные, специфические настройки сервисов, и т.п. Единственное пожелание - не смешивать файлы заголовков из NuTCRACRER и Windows.

Обычно приложение уже хорошо отлажено в своей родной среде, поэтому, если при переносе не использовались особые возможности Windows, то отладка проблем не вызывает. В нашем случае она свелась к обычной процедуре регистрации клиента DQS на сервере и внесении некоторых изменений в файл служб NT.

В целом весь процесс переноса с помощью системы NuTCRACRER прошел без проблем и занял три дня. При этом почти не потребовалось корректировать исходный текст. Были мелкие замечания, например в для NuTCRACKER отсутствовал прототип getpwduid(). Не было также функций getrlimit/setrlimit (учет расходования ресурсов), зато описание этих функций имелось в U/WIN, а ссылка была заменена программной заглушкой. Отсутствовал вызов wait3 (ожидание изменение состояния дочернего процесса), который пришлось заменить на waitpid с соответствующими параметрами.

Для работы Cygwin и любого приложения под ним, необходимо предварительно создать структуру каталогов, аналогичную Unix. Для этого потребовалось установить корень дерева каталогов с помощью команды mount. Обычно, в качестве корня выбирается один из дисков файловой системы Windows. Затем были созданы каталоги ?/tmp?, ?/bin?, ?/etc?, ?/usr?. В каталоге ?/bin? должен содержатся интерпретатор bash.exe, который либо непосредственно копируется, либо становится доступным после монтирования к соответствующему каталогу ?/bin? системы Cygwin. Далее, можно создать файлы /etc/passwd и /etc/group при помощи утилит mkpasswd и mkgroup. Нет необходимости создавать и наполнять каталог /dev (например, для создания /dev/null) - об этом заботится сама система Cygwin. Перед запуском оболочки потребовалось установить некоторые переменные окружения, явно указывающие пути к библиотекам.

После установки Cygwin есть опасность при запуске любого командного файла получить сообщение ?No such file or directory? или еще менее информативное. Причин такому поведению может быть несколько: не создан каталог ?/tmp?, нет файла bash.exe в путях поиска, каталог ?/tmp? недоступен на запись и др. В остальном Cygwin работает достаточно стабильно, а удобство его использование зависит от степени знакомства с ОС Unix.

Выводы

Из всех продуктов, предназначенных для переноса приложений между Unix и Windows, пристального внимания заслуживает NuTCRACKER. Эту систему имеет смысл по крайней мере изучить поподробнее с помощью версии, распространяемой во временное пользование. Этот продукт неплохо себя зарекомендовал при переносе критически важных Unix-приложений корпоративного уровня на платформу Wintel. По мнению аналитиков из Aberdeen Group он является сегодня лучшим инструментом миграции.

При работе с NuTCRACKER от программиста не требуется особо глубокого знания Windows - достаточно хорошо знать свое приложение и, естественно, Unix. Формируемая с помощью NuTCRACKER среда полностью повторяет исходную среду Unix, поэтому процесс переноса в Windows в данном случае сводится к задаче переноса между клонами Unix.

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

Автор выражает признательность Виктору Коваленко (ИПМ РАН) и Андрею Полевому (МГУ им. М.В. Ломоносова, ВМК, кафедра системного программирования) за помощь в подготовке статьи.

Там, где начинается Windows

Для адаптации Unix-приложений к работе в среде Windows ПО Cygwin выполняет ряд ухищрений, позволяющих обойти присущие этой операционной системе ограничения.

При работе приложения, обращающегося к функциям динамической библиотеки Cygwin, происходит загрузка кода Cygwin в сегмент кода приложения. Следуя требованию эмуляции ядра Unix, которое имеет доступ ко всем запущенным процессам, первый запуск Cygwin.dll приводит к созданию пула разделяемой памяти, где работает любой процесс приложения. В этой памяти хранится общая для Unix-подсистемы информация (например, дескрипторы открытых файлов), а также служебные данные, используемые для реализации fork и exec. Помимо общей памяти, каждый процесс хранит свою структуру данных: идентификатор процесса, идентификатор пользователя, маски сигналов и т.п. Так как разделяемая память в «ядре» в текущей версии Cygwin не защищена от несанкционированного доступа, это может привести к непрогнозируемому поведению программы. В Windows 9x не существует механизма защиты разделяемой памяти, а в реализации этого механизма для Windows NT есть «дыра». Поэтому Cygwin не следует применять для приложений с повышенными требованиями к безопасности.

Сложная модель модель безопасности - ACL, используемая в Windows NT поддерживается Cygwin путем отображения прав владения и доступа к файлам Windows на классическую модель Unix. А реализация системного вызова chmod осуществляет обратное отображение. Поскольку некоторые Unix-программы обращаются к файлам /etc/passwd и /etc/group, то Cygwin включает утилиты по созданию этих файлов на основе системной информации Windows NT.

Символьные ссылки (symbolic link) в Windows не поддерживаются, поэтому их необходимо эмулировать с помощью специальных файлов-связей, содержащих информацию о реальном местоположении файла. В Windows 9x все файлы всегда доступны на чтение, поэтому Cygwin использует системный атрибут read-only для определения того, доступен ли файл на запись. Файлы всегда доступны на исполнение, если имеют расширение имени .bat, .com, .exe или если их содержание начинается с символов ?#!?. Как следствие, утилита chmod имеет возможность устанавливать только флаг «w» (право записи) и игнорирует любые действия, связанные с другими режимами. В NT по умолчанию устанавливаются те же правила, что и в Windows 9x. Однако Cygwin делает порядок доступа к файлам более похожим на Unix. Для этого предусмотрено включение ключа ntea в переменную окружения CYGWIN. Когда флаг ntea включен, Cygwin использует в качестве исходных базовые права доступа на файлы, как в Windows, одновременно храня в расширенных атрибутах NT описание прав в смысле POSIX.

В Win32 API нет системного вызова fork, и реализовать его достаточно трудно. При порождении дочернего процесса, родительский выделяет и инициализирует пространство в таблице процессов Cygwin. Затем он создает приостановленный дочерний процесс, используя для этого системный вызов Win32 CreateProcess. Далее, родительский процесс при помощи системного вызова setjmp устанавливает точку перехода, чтобы сохранить свой контекст к точке возврата в прерванной работе. Указатель на этот контекст устанавливается в разделяемой памяти библиотеки Cygwin. Затем родитель заполняет секции .data и .bss дочернего процесса, копируя эту информацию из своего адресного пространства. Итак, копия процесса создана. После завершения инициализации адресного пространства дочернего процесса он запускается на исполнение, а родительский процесс ожидает освобождения объекта синхронизации (mutex1). Дочерний процесс обнаруживает, что он был скопирован (fork) и совершает переход по вызову setjmp, используя сохраненную родителем информацию о контексте в библиотеке Cygwin.

Затем, дочерний процесс освобождает объект синхронизации (mutex1), ожидаемый родителем, и сам блокируется на другой объект (mutex2). Это дает возможность родителю скопировать свой стек и память. После этого родительский процесс освобождает объект (mutex2), ожидаемый потомком и возвращается из вызова fork, осуществляя переход на сохраненный контекст. В это время потомок проходит точку синхронизации (mutex2), заново инициализирует память, основываясь на информации из разделяемой памяти библиотеки, и выходит из fork.

Алгоритм этот достаточно запутан и не очень эффективен, но в большинстве случаев семейство реализованных в Cygwin функций spawn, заменяет пару fork/exec, что увеличивает их эффективность. Надо отметить, что и с вызовами spawn и exec связаны некоторые трудности. Поскольку невозможно идентично реализовать вызов exec на платформе Win32, Cygwin вводит свои идентификаторы процесса (PID). В результате, если программа осуществляет множество вызовов exec, один PID от Cygwin будут соответствовать нескольким Windows PID. В некоторых случаях ожидание завершения процесса будет затягиваться.

Несколько слов по поводу реализации сигналов. Когда стартует процесс Cygwin, запускается вторая нить, которая используется для обработки сигналов. Эта нить ожидает событий Windows, передающих сигналы между процессами. Как только процессу приходит сигнал, оператор сигналов сканирует битовую маску сигналов и вызывает соответствующий обработчик.

Некоторые трудности в реализации механизма сигналов возникают как следствие того факта, что оператор сигналов выполняется в том же адресном пространстве, что и сама программа. Из этого следует возможность прерывания системой выполнения функций Cygwin. В Cygwin реализован некоторый механизм для предотвращения прерывания вызова sig_send. Когда один процесс посылает сигнал другому, он упаковывает вызов sig_send в объект синхронизации (mutex). Таким образом, исключается прерывание посылки сигнала другим приложением Cygwin. В случае посылки сигнала самому себе, в Cygwin используется пара семафор/событие. При вызове sid_send семафор сбрасывается, а его счетчик увеличивается на единицу. Обработчик сигнала считывает семафор, уменьшая счетчик, и обрабатывает сигнал, после чего порождает событие. Такая реализация сохраняет синхронизацию обработки сигналов внутри процесса, как этого требует POSIX.

Для реализации сокетов в Cygwin использовалась библиотека

Microsoft Winsock. Одно из самых заметных отличий от семантики Unix - необходимость инициализации Winsock перед первым вызовом любой из его функций, поэтому Cygwin вынужден осуществлять инициализацию во всех местах, где это необходимо. Например, для поддержки сокетов при вызовах fork, порожденный процесс сигнализирует Winsock, если хотя бы один из наследуемых дескрипторов файла является сокетом.


Unix-приложения на платформе Windows
  • Возможность использования недорогих Windows-ПК вместо дорогостоящих Unix-станций для выполнения широкого круга задач по отладке приложений, их тестированию и управлению процессом разработки.
  • Оптимальная загрузка имеющегося компьютерного парка за счет возможности сосуществования на одной платформе разных приложений.
  • Снижение нагрузки на Unix-серверы и их более глубокая специализация на выполнение наиболее приемлемых для них задач.
  • Защита инвестиций в имеющиеся Unix-программы за счет обеспечения их миграции в различные операционные среды.

Система DQS

Система разработана в Институте суперкомпьютерных вычислений университета шт. Флорида (http://www.scri.fsu.edu) для управления распределенными вычислительными ресурсами, образованными из гомогенных или гетерогенных сетей компьютеров. DQS обеспечивает распределение потока пакетных заданий по имеющимся ресурсам с целью повышения пропускной способности кластера, работающего с точки зрения пользователя как единое целое.

Кластер состоит из нескольких ячеек - компьютерных узлов и программного обеспечения, которое осуществляет единое администрирование. Можно сформировать в кластере несколько независимых или связанных ячеек, вместе образующих вычислительный узел. Базовым механизмом ячейки является организация взаимодействия демона, мониторов, работающих на каждом компьютере и служебных программ управления запуском заданий (Qsub, Qstat, Qmod и др.).

Задание для DQS - это командный файл, включающий Unix-сценарии и директивы DQS, который запускается утилитой Qsub. Система поддерживает планирование и управление для параллельных заданий (средства PVM, TCG/MSG, p4/p5, MPI), выполняемых на двух или более узлах кластера.

В 1992 году DQS была лицензирована компанией GENIAS Software и начала продаваться под именем Codine (Computing in Distributed Networked Environments). На настоящий момент имеются реально работающие конфигурации из 500 узлов, среди которых могут быть платформы RS6000/AIX 3.2, DEC/OSF, DEC/Ultrix, HP/HP-UX, Cray UNICOS, SGI/Irix, SPARC/Solaris и Intel/Linux.


Каждому свое

Естественно, у инструментов переноса есть определенные ограничения.

Так, ПО Interix построено на POSIX и не способно работать с Windows 95/98. С помощью этой системы невозможно создание смешанного кода, одновременно использующего функции API-интерфейса Unix и вызовы из Win32. Система Interix не поддерживает нити (threads), однако спецификация AKA PThreads включена в POSIX.1c и вошла в стандарт Unix 98, подготовленный X/Open, поэтому в следующих версиях Interix, как предполагается, этот недостаток будет устранен. Interix не поддерживает работу с DLL. Отсутствует поддержка последовательных портов и работы с символическими ссылками. Нет эмуляции терминала vt100 и механизма RPC. Отсутствует редактор emac, вместо него имеется редактор JOVE.

U/WIN не поддерживает технологию нитей, что является серьезным ограничением для Unix-приложений, работающих на SMP-платформах и в распределенной среде. Поддержка tcl/tk в U/WIN осуществляется частично - возможна компиляция для tcl/tk 8.02, однако работа tk осуществляется только в рамках базовых графических средств.

В Cygwin32 пока не реализован механизм нитей. Несмотря на обширную поддержку Cygwin32 средств разработки GNU, все они очень зависят от семантики Unix. В последующих версиях компилятора будет предусмотрена возможность подключения DLL для работы с Win32, а не с Cygwin32. В отличие, например, от U/WIN, в Cygwin32 недостаточно полно проработана поддержка модели безопасности Unix.


Полезные ссылки
Is NT Ready for the Data Center?

Joseph P. McGarvey, Windows Pro Magazine, 26 August 1998.

Linux legitimacy rallies NT skeptics.

R. Scott Raynovich, Polly Sprenger, LAN Times, 17 August 1998.

Wait on NT 5.0. Ben Heskett, CNET News.Com, 6 August 1998.

Users Should Skip NT 5.0. David Wilby,

TechWeb, 29 June 1998.

Engineers Speak Out: Linux vs. Windows NT, Part 1 by Murry Shohat, Intergrated

System Design Magazine, July 1998.

Interoperability: Possibility or Elusive Dream? An Executive White Paper

by The Aberdeen Group, March 1998.

An In-Depth Analysis of Five Commercial UNIX Operating Systems and Windows NT Server 4.0 (Enterprise Edition).

D.H. Brown Associates.

UWIN - UNIX for Windows. David G. Korn, Proceedings of the 1997 USENIX Windows NT Annual Technical Conference.

OpenNT: UNIX Application Portability to Windows NT via an Alternative Environment Subsystem. Stephen R. Walli, Proceedings of the 1997 USENIX Windows NT Workshop Proceedings.

Теоретическое введение в проблематику переносимости программного обеспечения: http://www.cs.wvu.edu/~jdm/research/portability/home.html

Литература
[1] Виктор Коваленко. Тысяча ПК или один «Крей». «Computerworld Россия», №25, 1998, стр. 42; http://www.osp.ru/cw/1998/25/42.htm.

[2] I. Foster, C.Kesselman, Globus: A Metacomputing Infrastructure Toolkit. Intl J. Supercomputer Applications, 11(2): pp. 115-128, 1997.

[3] Виктор Коваленко. OpenNT: Unix для NT. «Открытые системы», №3, 1997, cтр. 42-45; http://www.osp.ru/os/1997/03/42.htm.