Знакомство с Linux. Часть 23. Приручаем Windows

Мир шумит: в двоичном коде одного из служебных файлов MS Office обнаружен нецензурный стишок, написанный транслитом по-русски - привет неведомого программиста легионам тестировщиков Самой Любимой Корпорации. То есть, стишок наверняка предназначался автором не им, но не был выявлен своевременно, и попал в финальный официальный релиз программы. А значит, прошёл мимо внимания тех, кто отвечает за проверку кода перед публикацией. Стишок - всего лишь текстовая вставка в бинарный файл, то есть с точки зрения программы это просто неисполняемый участок кода. Комментарии нужны в исходном тексте - а какой от них прок в готовом двоичном файле? Значит, любой неисполняемый участок кода должен вызывать подозрение и провоцировать тщательное расследование. А вдруг это "троянский конь" или иная разновидность логической бомбы? Выходит, не так уж педантично тщателен контроль кода в Microsoft. Впрочем, это - не тема нашего разговора.

Однако наша тема находится, тем не менее, в прямой связи с Windows. Поговорим о том, каким образом перебросить мостик между Linux - в варианте Fedora Core 1 в данном случае, хотя детализация тут не принципиальна - и операционной системой разработки Microsoft. Точнее, приложениями, бинарными исполняемыми файлами, скомпилированными для неё. Поставим вопрос так: можно ли заставить эти файлы исполняться под Linux?

Вопрос совсем не праздный. В мире свободного ПО есть немало аналогов Windows-приложений. Вам нужен мощный текстовый редактор? Попробуйте AbiWord или OpenOffice.org. Электронная таблица? Ну скажем, Gnumeric. Программа обработки растровых изображений? Однозначно GIMP. И так далее... Но всё же бывают ситуации, в которых использование самого Windows-приложения, а не его аналога, совершенно необходимо. Ну скажем - ABBYY FineReader прекрасно распознаёт русский печатный текст, в то время как OCR-программы под Linux "заточены" всё же главным образом под латиницу, и конкурировать с изделием отечественных мастеров программирования на нашей почве - объективно не в состоянии. Конечно, можно перезагрузить компьютер в Windows, если на машине установлены обе системы (а как правило, это для большинства домашних ПК современных линуксоидов верно), отсканировать и распознать текст, затем вернуться в Linux и продолжить работу там. Но осадочек-то останется.

А игры? Да, FreeCiv на старших уровнях сложности покорит сердце любого поклонника мейеровских "Цивилизаций", и даже аскетичность дизайна игрушки не смажет впечатления от силы её "искусственного интеллекта". Да, шахматные программы для Linux очень неплохи. Да, есть масса несложных (по реализации) и привлекательных логических игр. Есть даже возможность играть в OpenGL-игры вроде всех разновидностей Quake и Return to Castle Wolfenstein. Но вот подавляющее большинство современных трёхмерных игр, где существенно использование библиотек DirectX, остаётся за бортом Linux. Несправедливо!

Тем более несправедливо, что никакой особенной магии в Windows как таковой нету. Это обычная операционная система - а, как известно, в одной ОС можно с успехом эмулировать другую. Если мощность процессора позволяет, конечно, и если известны принципы работы подвергаемой эмуляции системы. Вот именно с последним пунктом в нашем случае - закавыка, поскольку Windows всё-таки не зря является системой с закрытым кодом. Построить эмулятор Atari или Commodore 64 - это одно, а скопировать поведение ОС от Microsoft в чужеродной для неё среде - совершенно другое.

Но дело, как известно, мастера боится, и Linux-программисты достаточно успешно решают эту непростую задачу. Есть несколько проектов, ставящих своей целью позволить запускать в Linux-среде Windows-приложения, но остановимся мы с вами сейчас на наиболее известном и амбициозном из них, на Wine и его развитии - WineX. На первом - несколько подробнее, просто потому, что он для нас с вами гораздо доступней.

Итак, первым делом раздобудем исходный код Wine. Отправляться за ним следует на домашнюю страницу проекта www.winehq.com, в раздел Download. Рекомендую загружать именно исходный код среды, а не бинарные rpm-пакеты. Далее будет видно, что оперировать с исходниками, играя настройками системы, очень просто, да и компилируя программу на собственной машине, вы получаете гарантию её полной работоспособности - если она успешно скомпилировалась, конечно. В каталоге доступных к загрузке версий Wine номера версий соответствуют датам их выпуска. На момент написания этой статьи самой свежей была Wine-20040121.tar.gz - и именно с ней в качестве примера я и работал дальше.

Итак, закачиваем Wine - к сожалению, в исходную поставку Fedora Core 1 она не входит. Сожаление становится особенно острым, когда видишь, что gzip-архив программы занимает более 9 Мбайт... Но что делать, искусство уже привыкло требовать жертв. Рассчитавшись с искусством, скопируйте свежедобытый дистрибутив в каталог /usr/local/src и распакуйте - поскольку архив tared&gzipped, используйте опцию z:

tar xvzf Wine-20040121.tar.gz

Далее перейдите в появившийся каталог (wine-20040121, соответственно) и выполните... нет, не стандартную связку ./configure - make - make install. Wine снабжена удобной командной оболочкой, которая сама в нужное время попросит вас ввести пароль root и сама проконтролирует конфигурацию системы. Отдайте команду

./tools/wineinstall



Первым запустится конфигуратор, который уточнит расположение необходимых для компиляции системных ресурсов. Затем Wine напомнит вам, что инсталлировать её следует от имени суперпользователя, и спросит - готовы ли вы будете ввести пароль root по запросу конфигуратора. Отвечайте yes (именно yes, не просто y); в противном случае придётся последний шаг установки выполнять вручную. Любопытно, насколько тщательно разработчики этой среды следуют кодексу UNIX-security. Обычно народ, далёкий от проблем системной безопасности, не сильно беспокоится соблюдением прав кода при компиляции исходников: входят в систему как root и выполняют все операции чохом. А компилировать как раз нужно именно и только из-под логина с обычными привилегиями; для того же, чтобы выполнить make install, необходимы суперправа. Так вот, если вы попробуете запустить wineinstall сразу из-под root, то ни к чему это не приведёт - инсталлятор пожурит вас за неосмотрительность и предложит не зарываться с правами.

Итак, работа конфигуратора продолжается выходом на сцену собственно компилятора. На экране терминала пролетит ехидное сообщение о том, что неплохо бы вам, уважаемый пользователь, пообедать разика два, сходить в видеопрокат за кассетой, или ещё чем-нибудь себя занять - потому что процедура предстоит долгая. На моём стареньком Athlon 1000 с 512 Мбайт памяти компиляция шла около получаса, так что идея с обедом - и впрямь достаточно здравая.

Дальше всё просто: компиляция завершится, конфигуратор запросит у вас пароль суперпользователя, вы его введёте - и среда Wine будет проинсталлирована. В процессе, правда, вам зададут ещё вопрос. А именно: использовать ли движок самой Windows, что уже установлена на вашем компьютере, для работы Wine? Или - пусть справляется своими силами?


Разумеется, такой вопрос будет задан лишь в том случае, если на одном из разделов вашего винчестера действительно присутствует Windows - и раздел этот подмонтирован в Linux. Суть в том, что Wine - действительно не просто эмулятор (его наименование и разворачивается как WINE Is Not an Emulator); не эмулирует работу процессора и другого "железа" системы, чтобы заставить лицензионную копию Windows "проинсталлироваться" на эту виртуальную машину. Wine воссоздаёт своими собственными, оригинальными средствами работу Windows API - то есть для программ, скомпилированных в среде ОС от Microsoft, взаимодействие и с Windows, и с Wine в идеале окажется одинаковым: системные вызовы, которыми будут обмениваться приложение и среда, окажутся в обоих случаях идентичными. Вот только реализация их будет разной. Это, собственно, и есть известный принцип "чёрного ящика": поведение сигнала на его входах и выходах известно и ожидаемо, а что там внутри - не так уж и важно. В любом случае, если вам надоест пользоваться оригинальными Windows-библиотеками, всегда можно вернуться в каталог, где хранится исходник Wine, и перекомпилировать среду. При повторной компиляции пересборки самого кода происходить уже не будет - зато, ответив "no" вместо "yes" на вопрос об использовании Windows DLLs, вы освободите себя от последних оков корпорации.

Как работать с Wine далее? Разумеется, можно - и нужно - изучить документацию, доступную и по командам man wine и man wine.conf, и на сайте проекта, и в подкаталоге documentation установочной директории среды. Но всё гениальное просто, и элементарные действия - такие как исполнение одного-единственного Windows-файла - получаются с использованием Wine легко и непринуждённо. Просто наберите в строке терминала или "графической" командной панели, вызываемой в KDE по Alt+F2,

wine имя_файла

...и дело в шляпе. Так, напритмер, замечательно воспроизводятся "экзешные" мультики с Масяней, скачанные с куваевского сайта в формате zip и затем распакованные - кстати, утилита zip в Linux прекрасно себя чувствует; если хотите узнать о её работе, наберите традиционное man zip.


Так вот, к вопросу об эмуляции. Wine воспроизводит (достаточно успешно) значительную часть существующего сейчас Windows API - ведь проект развивается с 1993 года, и первоначально предназначался для работы с приложениями Windows 3.1 (бинарники MS DOS линуксоиды к тому времени уже уверенно освоили - такие эмуляторы, как DOSEmu, появились ещё раньше). Больше того, некоторые участки кода работают даже лучше, чем имитируемые, хотя на современных скоростях и тактовых частотах это не так уж принципиально. Однако если есть возможность, почему не воспользоваться готовыми, оригинальными DLL? Особенно если ваша Windows с соседнего раздела диска - лицензионная?.. Зато пуристы от Linux наконец-то вздохнут спокойно: множество приложений можно теперь запускать, вообще не касаясь враждебного кода.


Множество, но не все. Всё-таки - не все... Взять те же современные игры - да, за стремительным развитием DirectX не могут угнаться и разработчики Linux-драйверов под видеокарты, что же говорить о воссоздании необходимого для игр API... Да, OpenGL в Linux работает замечательно. Кто знает, может, потому Самая Любимая Корпорация - а вслед за ней и подавляющее большинство разработчиков игр - делает ставку на DirectX? В любом случае, с невозможностью запустить нежно любимых "Демиургов" из-под Linux нам с вами придётся смириться.

Или - если смиряться не хочется - посетить сайт компании TransGaming, поставившего своей целью сделать невозможное возможным. По отзывам тех, кто имел дело с проектом WineX, среда от TransGaming действительно расширяет возможность эмуляции самых современных особенностей Windows до невиданных высот. Однако скачать себе дистрибутив проекта и насладиться им в полной мере дано не всем - радость подписки на WineX обойдётся вам в $5 в месяц. Да-да, речь идёт именно о подписке, а не о разовой покупке. И трудно упрекать создателей этой среды в предательстве светлых интересов сообщества свободного ПО: работа их действительно сложная, выполняется оперативно, в свободное время ей не займёшься - и результат получается достойным. Так что требовать за него плату - их право. Однако одновременно это означает, что самые свежие Windows-радости нам с вами недоступны. Нет, пятёрка в месяц - деньги не такие большие, но сложности при оплате по кредитным картам из России таковы, что мало кто захочет с ними связываться...

Так что, похоже, ещё какое-то время придётся нам играть в Windows-игры под управлением специально для того предназначенной платформы. Как минимум. До тех пор, пока основная ветка проекта Wine не пополнится кодом поддержки DirectX. Дождёмся ли?