Наверное многие из наших читателей хотя бы раз в жизни использовали "неэмулятор" WINE (WINE - акроним - Wine Is Not an Emulator). Но далеко не все озадачивались исследованием каких либо дополнительных возможностей,O кроме запуска Windows-приложений под *nix-системами. Да и не высокую скорость запуска этих приложений списывали на то что это только альфа-версия. Однако если немного углубиться в устройство Wine - можно очень не плохо оптимизировать его работу и найти в нём ряд дополнительных интересных возможностей.

Начнём с установки wine (если кто-то ещё этого не сделал:)):

# Для Debian/Ubuntu/ALT Linux:
apt-get install wine

# Для Mandriva:
urpmi wine

# Для Gentoo:
emerge wine

# Для FreeBSD:
cd /usr/ports/emulators/wine && make install clean

Далее приступаем к исследованию wine. Первым делом посмотрим в сторону winecfg - основному инструменту конфигурации wine. С его помощью можно настроить большую часть основных параметров wine.

Внешний вид winecfg

Хотя winecfg и не содержит никакой подсказки - её интерфейс прост и интуитивно понятен и с ним сможет разобраться даже достаточно неопытный пользователь.

Здесь можно настроить версию Windows, которую будет "видеть" программы, цветовую схему всех приложений, работающих под Wine, настроить эмуляцию дисков, вывод звука, параметры трёхмерной графики и многое другое.

Эта утилита сохраняет все свои настройки в файлах с расширением .reg в каталоге ~/.wine. В этих же файлах лежит и реестр "виртуальной" Windows, в которой работают приложения. Для редактирования реестра не плохо подойдёт утилите regedit, аналогичная и внешним видом и функционалом одноимённой утилите из windows.

Однако при всей мощи этих двух утилит, они всё-таки не позволяют управлять всеми аспектами работы wine.

Внешний вид wine regedit

Рассмотрим как происходит запуск windows приложения при помощи wine. Первым делом wine проверяет не запущен ли wineserver. Если запущен то wine подключается к нему и начинать транслировать вызовы запускаемого приложения в вызовы wineserver. Если же wineserver не запущен, то сначала запускается wineboot, который запускает wineserver и затем эмулирует начальную загрузку windows, после чего wine подключается к wineserver и начинает транслировать вызовы приложения в вызовы wineserver.

Отсюда видно что первый запуск любого приложения под wine всегда проходит очень долго и встаёт разумный вопрос: как можно его ускорить?

Очевидно что к моменту запуска windows-приложения процесс начальной инициализации wineserver должен быть уже завершён. Эта задача решается достаточно легко. Например если вы работает в KDE то просто создайте симлинк:

ln -s `which wineboot` ~/.kde/Autostart

И wineboot будет автоматически запускаться при входе в систему.

Ещё одной интересной особенностью wine является компилятор winegcc, который позволяет писать кроссплафторменный код на C. Вернее даже сказать что он позволяет собирать написанные на C windows-приложения под *nix. В итоге получается нативное приложение, использующее библиотеки wine. Так же можно писать новые программы используя библиотеки wine как тулкит (не уступающий по функционалу таким мострам как qt и gtk).

В некоторых дистрибутивах всё необходимое ставится вместе с wine, в других же придётся установить дополнительные пакеты:

# Для Debian/Ubuntu:
apt-get install wine-dev gcc-3.4

# Для ALT Linux:
apt-get install libwine-devel

# Для Mandriva:
urpmi libwine-devel

Далее создадим файл winehello.c и наберём в нём простенькую программу:

#include <windows.h>

int main()
 {
  MessageBox(0, "From Russia with love!", "Message", MB_OK);
  return 0;
 }

Сохраним файл и скомпилируем приложение:

winegcc winehello.c -o winehello

Приложение winehello

Далее запустим полученое приложение командой ./winehello. На экране должно появиться простое диалоговое окно wine с заголовком "Message", текстом "From Russia with love!" и кнопкой "OK". При нажатии на кнопку окно закроется и приложение завершится.

Это было нативное приложение Linux (или другой системы, в которой вы это проделывали), но использующее для своей работы библиотеки wine. На самом деле конечно winegcc компилириует не совсем в бинарный файл. Он собирает библиотеку и добавляет к ней скрипт запуска. Выполните команду ls -lh и вы это увидите:

итого 88K
-rwxr-xr-x 1 moose moose 700 2008-03-16 00:39 winehello
-rw-r--r-- 1 moose moose 112 2008-03-16 00:39 winehello.c
-rwxr-xr-x 1 moose moose 75K 2008-03-16 00:39 winehello.exe.so

Здесь winehello.c это исходный текст, winehello.exe.so это библиотека и winehello это скрипт, запускающий нашего приложения. Вместо него вполне уместно использовать команду:

wine winehello.exe.so

В том что winehello.exe.so является действительно нативной библиотекой а не исполнимым файлом формата PE можно убедиться при помощи команды file winehello.exe.so:

winehello.exe.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped

А просмотреть необходимые библиотеки можно с помощью команды ldd winehello.exe.so:

        linux-gate.so.1 =>  (0xffffe000)
        libwine.so.1 => /usr/lib/libwine.so.1 (0xb7ddb000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7db6000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c6b000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c67000)
        /lib/ld-linux.so.2 (0x80000000)

Так что теперь можно смело писать в *nix программы на WinAPI и они будут нормально работать. Но что самое интересно - используя библиотеки wine можно пересобирать написанные под windows приложения в *nix не меняя их кода!

Подробную документацию по WinAPI можно найти например в MSDN.

Автор надеется что эта статья была интересна читателю и возможно даже принесла некоторую пользу.