Мир шумит: в
двоичном коде одного из служебных файлов 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. Дожд╦мся ли?
 Внимание: ссылки
работоспособны на момент
публикации материала. Сайт www.fcenter.ru
не нес╦т ответственности за
изменения на сторонних серверах.
|
|
