Опасности на пути из Unix в NT

Дэвид С. Линтикум

По мере того, как Windows NT завоевывает все большую долю рынка систем клиент-сервер, перенос некоторых Unix-приложений в среду NT станет неизбежным. Но их перенос - процесс непростой.

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

NT нашла свой собственный путь в корпоративную структуру через настольную систему, область, в которой традиционно сильна корпорация Microsoft, и через локальные сети, где лидером была ОС NetWare компании Novell. Успех NT в равной степени обусловлен основательным маркетингом Microsoft и тем, что продукт отвечает разумным техническим требованиям, которым не слишком хорошо соответствовали Windows или Novell NetWare.

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

Хотя клиенты Windows 95 и Windows NT легко соединяются с серверами, работающими под управлением Unix, многие организации склоняются к использованию NT также и на сервере. Ее графический пользовательский интерфейс знаком большинству пользователей, и приложения, основанные на интерфейсах прикладного программирования Win32 API и выполняющиеся на рабочих станциях, смогут также выполняться и на сервере. Абсолютно естественно, что лучшим сервером для рабочих станций NT будет сервер Windows NT.

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

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

Муки переноса

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

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

Организации занимаются переносом Unix-приложений по различным причинам. Например, многие Unix-приложения, которые работают с серверами баз данных, рано или поздно придут к Windows NT, поскольку NT охватывает большую часть рынка серверов младшего класса. Разработчики вынуждены переносить приложения, для того, чтобы увеличить круг своих потребителей, а также продемонстрировать, что их приложения столь же гибки, как и другие, которые уже переносятся в среду Windows NT. Обычно эти приложения не графические и, следовательно, не требуют столь значительного переписывания, как этого требуют при переводе на Win32 приложения, использующие графический пользовательский интерфейс Unix, в первую очередь OSF/Motif.

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

Приложения, которые переносятся с Unix на NT, обычно являются высококритичными и меняют платформу для того, чтобы увеличить число своих пользователей или поддерживать аудиторию, которая переходит на Windows NT. Среди переносимых приложений самые разные, от программного обеспечения вертикального рынка, такого как системы для продажи одежды или практики зубного врача, до всеобъемлющих продуктов, таких как большие бухгалтерские системы и системы управления сетями. Более того, с увеличением числа заказов на NT-версии брокеров объектных запросов (ORB, Object Request Broker) распределенные объектные приложения также распространяются на Windows NT, как и на Unix.

Некоторые приложения, еще не созданные, разрабатываются изначально c ориентацией на переносимость. Таким продуктом будет несколько проще управлять, так как проектировщики и разработчики могут создавать приложения с начала до поддержки переносимости с ОС Unix на NT. Но выбор ошибочной стратегии, определяемой стремлением сделать приложение переносимым, может плохо повлиять на дальнейшую судьбу приложения. Мир приложений чрезвычайно богат ловушками переносимости.

Орехи и сито

Когда вы рассматриваете вопрос о переносе приложений на Windows NT, в первую очередь обратите внимание на новые инструментальные средства и ресурсы, недоступные на NT, а также на изменения исходного текста. В Windows NT нет многих ключевых возможностей, на которые рассчитывает каждый Unix-программист.

Большинство Unix-разработчиков привыкают к множеству мощных утилит Unix, таких как awk, sed, lex и grep. Вы не найдете их в Windows NT. Однако, большинство из этих инструментальных средств можно приобрести у производителей коммерческих продуктов, таких как Hamilton Laboratories и MKS. Они предоставляют Unix-утилиты, встроенные в Windows NT, которые позволяют попавшим в чужеродную среду Unix-разработчикам чувствовать себя более комфортно.

Как и Unix, Windows NT - преимущественно многозадачная, многопользовательская, многопоточная операционная система. NT может запускать не только приложения, созданные на основе Win32, но и приложения Posix и OS/2 (только символьные). Эти подсистемы обеспечивают и системные вызовы, и надлежащие переменные окружения для приложения.

Unix и NT имеют много общего, в том числе модель многопользовательского программирования, модель программирования процесс/поток с 32-мя уровнями приоритетов, встроенный механизм вызова удаленных процедур (RPC, Remote procedure Call), сокеты, файловые системы, которые используют длинные имена файлов и плоскую 32-разрядную модель памяти. NT также обеспечивает функции синхронизации процессов и асинхронный ввод/вывод.

Все это свидетельствует, однако, о том, что многие концепции изменяются, когда вы переносите приложения с Unix на Windows NT, в том числе использование циклов сообщений, взаимодействие приложение-приложение с применением Dynamic Data Exchange (DDE), Object Linking and Embedding (OLE), OLE Automation и Distributed Component Object Model (DCOM, раньше называвшегося Network OLE). Те, кто переносит приложения на Windows NT, также должны представлять себе ресурсы и результаты работы функций, и вам придется изменить компилятор и интегрированную среду разработки приложений.

Для простых приложений типа Hello, World!, разработчики увидят, что стандартный C-код хорошо компилируется и работает под Windows NT как только символьное приложение. Конечные пользователи, однако, требуют приложения на основе GUI с присущим им интерфейсом. Для того, чтобы использовать полное множество возможностей NT, разработчики должны переписать приложения с тем, чтобы использовать "родные" вызовы Win32.

На уровне интерфейса Windows NT обеспечивает Graphical Device Interface (GDI), часть Win32 API. GDI включает в себя объекты и управление окнами. На любом уровне он значительно отличается от имеющихся в Unix API, таких как Xlib, Xt и Motif. Однако, Unix-разработчики, которые переносят свои идеи, а также свой код на NT, будут счастливы узнать, что GDI обеспечивает "супермножество" возможностей X Window System. Конечно, эти возможности нуждаются в полностью пересмотренном множестве системных вызовов.

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

Различия между приложениями Unix и Windows NT заставит большинство организаций разработчиков Unix двигаться медленно, когда дело касается перехода на NT. Например, существуют свободно распространяемые утилиты, такие как ntxlib.zip, которые разрешают использовать вызовы к Win32 API. Все программные отличия между Unix и Windows NT выходят за рамки этой статьи, но понимание того, как меняются некоторые вещи, может помочь вам представить, как перенос повлияет на ваше приложение.

К примеру, при вводе/выводе файлов в Unix-системах используются функции fopen(), fread(), fwrite(), fprint() и fclose(). Эти функции как раз очень легко применять для символьных приложений Windows NT, но Windows NT требует, чтобы разработчики применяли CreateFile(), ReadFile() и WriteFile() для того, чтобы воспользоваться мощью 64-разрядного доступа к файлам и асинхронного ввода/вывода. Более того, файловая система Windows NT может не использовать представления i-node (идентификатор файлов в "классических" вариантах ОС Unix), поэтому Unix-приложения, которые рассчитаны на структуру i-node, не будут должным образом работать с Windows NT.

Мобильность за счет инструментария

Прямой перенос программного кода с Unix на NT - не единственная возможность для разработчиков. Для тех, кто не хочет создавать или переписывать приложения для обеих систем, Unix и Windows NT, существуют несколько библиотек и инструментальных средств переноса независимых производителей. К этим продуктам относятся Zapp компании Inmark Development, C++/Views компании Liant Software, XVT компании XVT Software и Zinc компании Zinc Software. Возможен также выбор среди многочисленных инструментальных средств разработки приложений, использующих языки четвертого поколения (4GL), которые переносимы между двумя операционными средами.

Кросс-платформенные библиотеки чаще всего представляют собой оболочки языка C++, которые могут воспользоваться преимуществами объектно-ориентированных возможностей C++ и разместить весь зависящий от платформы код (такой как Win32, Xlib или Motif) в библиотеке классов. Разработчик обращается к присущему операционной системе и службам GUI, используя собственные вызовы API. При переносе приложения из одной операционной системы в другую, разработчики просто заменяют соответствующую библиотеку и перекомпилируют программу.

Хотя в каждой кросс-платформенной библиотеке есть свой собственный подход к разработке и мобильности приложений, все они позволяют разработчику наслаивать "родные" API-интерфейсы на собственные API, обеспечивая таким образом переносимость приложения. Однако, что именно они делают с этим API-интерфейсом, варьируется от инструментария к инструментарию, и переносимость зачастую приходит за счет изменения интерфейса, неотъемлемо присущего приложению, и даже за счет потери производительности.

Некоторые кросс-платформенные библиотеки поддерживают только подмножество функций, которые имеются и в платформах Unix, и в Windows NT. Это означает, что вы не можете полностью воспользоваться преимуществами мощи некоторых возможностей NT, таких как DDE и OLE. Создатели кросс-платформенных библиотек выполняют хорошую работу, обеспечивая "родные" функции и возможности, но разработчики, использующие эти функции в своих приложениях, делают это за счет мобильности.

Другие кросс-платформенные библиотеки не беспокоятся о поддержке "родных" возможностей. Вместо этого, они эмулируют элементы управления GUI и в Unix, и в Windows NT, за счет написания кода непосредственно для графических подсистем каждой платформы. Неиспользование API-интерфейсов, принадлежащих платформе, может привести к некоторым странным результатам. Например, при использовании кросс-платформенных библиотек, которые поддерживают эмуляцию, переносимые приложения, написанные для Windows 3.5 при работе под Windows 4.1, который поддерживает интерфейс Windows 95, будут выглядеть "чужеродными". Другими словами, при изменении графического пользовательского интерфейса приложение не будет автоматически настраиваться, поскольку оно в действительности не использует "родной" API-интерфейс. Другие кросс-платформенные инструментальные средства воплотили лучшее из обоих подходов. Если "родной" элемент управления не доступен для того, чтобы обеспечить переносимое приложение с согласующимся интерфейсом, библиотека его эмулирует.

Компромисс в использовании кросс-платформенного инструментария - это переносимость за счет открытости и производительности. Так как вы создаете приложение, используя собственные API-интерфейсы, вы ограничены при работе с приложением рамками этого инструментария. Дополнительный уровень, который должно проходить приложение, может стать причиной потери производительности, так как для реализации интерфейса пользователя используются инородные механизмы. Однако применение этих инструментальных средств позволяет создавать мобильные приложения быстрее, чем когда разработчики пытаются сделать свои приложения "родными" для обеих платформ, используя два набора кодировок символов. Если ваша стратегия переноса приложений такова, то рассчитывайте на то, что вы потратите вдвое больше денег из-за увеличения срока разработки, равно как и из-за лишнего инструментария. Сейчас кросс-межплатформенные инструментальные средства и оболочки обеспечивают быстрое решение.

У операционных систем Unix и Windows NT много общих свойств, но в ключевых вопросах разработки они отличаются весьма существенно

Другие варианты переноса

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

Существуют, однако, несколько продуктов, обещающих легко добиться сосуществования приложений Unix и NT. Например, OpenNT System компании Softway Systems позволяет запускать приложения Unix и Win32, надстраивая подсистему Unix над ядром Windows NT. Softway выбирает прямую дорогу, лицензируя исходный текст Windows NT для того, чтобы создать команды и утилиты OpenNT. По словам Дэна Кузнецки, аналитика по системам Unix в компании International Data Corp., продукты такого рода предлагают наилучший способ получить приложения Unix и Windows NT, работающие вместе в одной и той же системе. Несомненно, это лучшее решение, чем эмуляция или запуск эмулятора X Window System на рабочих станциях под Windows NT.

Идущая другой дорогой MainSoft представила MainWin Extended Development Environment (XDE), среду разработки, которая позволяет переносить приложения, использующие Win32, в ОС Unix. MainWin XDE поддерживает элементы управления Windows NT и может работать под Hp-UX и SCO Open Server. Несколько других продуктов, подобных Wind/U компании Bristol Technology, обеспечивает пользователям возможность запускать NT-приложения под Unix.

NT и предприятие

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

При переносе приложения на Windows NT у вас есть несколько возможностей. Во-первых, вы можете реализовать оптимистический подход: запустить эмулятор X под Windows NT и надеяться, что никто этого не заметит. Хотя этот вариант позволяет завершить все работы примерно за неделю, эмуляторы не обеспечивают присущий приложению интерфейс и производительность, на которые, безусловно, рассчитывают пользователи.

Во-вторых, вы можете использовать подход "переноса мощности", при котором вы заставляете Unix-приложения работать под Windows NT, модифицируя текст программы, заменяя один API-интерфейс на другой. Этот подход требует больше времени и усилий, но позволяет вашим приложениям использовать большинство возможностей нового окружения. После реализации такого подхода, требуется провести тщательное тестирование приложения.

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

Наконец, вы можете реализовать подход, использующий возможности переноса, обеспечиваемые Posix и рассчитывать на подсистемы Posix в управлении вашими приложениями. Хотя это также быстрое решение, в Posix большинство функций и возможностей NT недоступны. Пользователи вскоре начнут избегать эти приложения, отдав предпочтение "родным" продуктам.

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

Посулы Posix

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

Для тестирования и подтверждения соответствия стандартам Windows NT 3.1 был использован NIST Posix Conformance Test Suite для Federal Information processing Standard (FIpS) 151-2. Таким образом, приложение, которое удовлетворяет спецификации Posix.1 и использует утвержденные языковые конструкции, будет работать с подсистемой Posix операционной системы Windows NT.

Приложения Posix (и подсистемы Posix, которые они используют) работают внутри своего собственного защищенного адресного пространства. Это значит, что другие "плохие" приложения, как Win32, так и MS-DOS, не смогут вызвать сбой приложений Posix. Posix-подсистема существует в Windows NT как защищенный сервер, а Posix-приложения взаимодействуют с подсистемой Posix посредством механизма передачи сообщений. Этот механизм передачи сообщений является частью NT Executive и получил название LpC (Local procedure Call - локальный вызов процедур, явно в противовес классическому Unix-овому удаленному вызову).

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

(c) Uniforum, 1996. Все права защищены. Переведено и печатается с разрешения международной ассоциации профессионалов в области открытых систем Uniforum.