Причины вайнофобии

Вот так выглядит пользовательский интерфейс одного Windows-приложения, запущенного под Mac OS X 10.6.2 с использованием самого последнего Wine 1.2rc2. И это, кстати, не статическая страничка. Та же самая программа несколькими секундами позднее выглядит так, как показано на второй картинке. Это произошло после того, как был собран из исходников и установлен требующийся этому приложению libXrender-0.9.5. В этой заметке я попытаюсь провести анализ того, почему многим так страшно работать с Wine. Почему опытные разработчики открещиваются от wine? Я бы выделил несколько причин.

Во-первых, wine - это "не красиво". Это искусственное образование, которое, по сути, является попыткой придумать свой windows по опыту наблюдения над настоящей windows как над черным ящиком.
К примеру, в wine есть собственная реализация библиотеки msxml3. Эта библиотека зачем-то нужна при регистрации COM-компонентов (dll), и regsvr32 падает на unhandled exception при использовании самописной msxml3. Именно поэтому есть такой "черный ход", когда самописная msxml3 подменяется на настоящую, взятую с windows (т.н. "нативная"). С нативной либой все нормально.
Второй пример. Есть своя собственная реализация gdiplus. Эта библиотека нужна для работы с графикой. Так вот, самописная реализация не написана, похоже, чуть более чем на половину, поскольку простейшие тестовые примеры, использующие gdiplus, не работают. Доступный в исходных кодах пример использования gdiplus, который позволяет рисовать полигоны и потом рисовать между точками плавные линии, не работает! Полигоны рисуются, а вот перерисовывать прямые линии на кривые уже не может. Тут на помощь опять-таки приходит winetricks, когда с настоящей windows берется настоящая библиотека gdiplus. С ней все работает нормально.

Во-вторых, это очень сложно. Очень сложно вести разработку для wine, модифицировать его исходный код, ввиду следующих особенностей:
- нет однозначного отображения пространства функций из Windows в Linux/Mac.
- исходного кода очень много, сотни мегабайт.
- существуют нетривиальные зависимости между компонентами системы. Например, показанные на картинках выше "эффекты" - это дело рук Xrender, компонента X11, т.е. реализации алгоритмов добавления "теней" вокруг окошек на основе использования альфа-канала (alpha blend). Именно так: чтобы система умела рисовать тени вокруг окошек, пришлось собрать из исходников Xrender (а это значит собрать вот такие пакеты в таком порядке: randrproto-1.3.1.tar.bz2 xineramaproto-1.2.tar.bz2 libXext-1.1.1.tar.bz2 libXfixes-4.0.4.tar.bz2 fixesproto-4.1.tar.bz2 compositeproto-0.4.1.tar.bz2 libICE-1.0.6.tar.bz2 X11-xshape-0.1.1.tar.gz libSM-1.1.1.tar.bz2 libXcomposite-0.4.1.tar.bz2 libXinerama-1.1.tar.bz2 libXrandr-1.3.0.tar.bz2 libXxf86vm-1.1.0.tar.bz2 libXi-1.3.tar.bz2 libXcursor-1.1.10.tar.bz2 renderproto-0.11.tar.bz2 libXau-1.0.5.tar.bz2 libpthread-stubs-0.3.tar.bz2 xcb-proto-1.6.tar.bz2 libxcb-1.6.tar.bz2 xtrans-1.2.5.tar.bz2 xextproto-7.1.1.tar.bz2 kbproto-1.0.4.tar.bz2 inputproto-2.0.tar.bz2 xproto-7.0.17.tar.bz2 libX11-1.3.3.tar.bz2 libXrender-0.9.5.tar.bz2 - 7 мб сильно сжатых исходников). И вот теперь получается, что в каком-то из этих пакетов ошибка, приводящая к такой вот красоте, как на картинках. Т.е. получается, что помимо исходников самого wine (126 мб), требуется еще ковыряться в багах X11 и возможно не только его.
- существуют "баги на багах, которые дают фичу". То есть бага в windows библиотеках и в приложениях, в результате все работает как надо. А если перенести это все в wine, то работать все перестает.

"Сложно" и "не красиво" это проблемы первого порядка. Если не иметь опыта управления проектами по разработке программного продукта, то эти две проблемы могут остановить любого.

Мне же видится, что с этими проблемами можно что-то сделать, чтобы они не казались такими страшными. На мой взгляд, это:
- разработка системы юнит-тестирования всего. Вообще всего. Это главная проблема, потому что это очень долго и трудоемко, но без этого никуда. Я подозреваю, что в самом "логове" (Microsoft) очередная сборка операционной системы проходит в буквальном смысле миллионы автоматических тестов. Тестируется каждый метод, каждая функция каждой библиотеки, и зоркие глаза тестовых скриптов внимательно следят за тем, чтобы все было как ожидается в тесте. При обнаружении баги проблемная dll локализуется, бага исправляется, запускается перетестирование.
В wine ничего этого, похоже, нет. Есть 17-летняя работа по написанию этого wine, но нет тестов. Странно. В их понимании, видимо, "тестирование" - это запуски разных программ под wine и присваивание им уровней совместимости "золотой", "серебряный", "бронзовый" - т.е. функциональное тестирование, а не юнит-тестирование.
- декомпозиция всех фич винды на маленькие тестовые примеры, эксплуатирующие одну конкретную фичу типа построения сплайнов по нескольким точкам.

Вот если иметь перед собой набор из 5000 фич, которые не работают в wine, и планомерно, хладнокровно, фиксить эти фичи одна-за-одной, то будет прогресс. Но это очень дорого по людям и затратам. И поэтому такой вариант не случится, поскольку он не окупит затрат.

Люди из WineSkin сделали уже очень многое. Они как раз решают две задачи, важные с точки зрения практического применения wine под Mac OS:
- они вкручивают в него собственную сборку X11
- добавляют обертку для представления wine + win приложение в качестве настоящего приложения Mac, с маковским меню.

На данный момент я вижу работу в использовании наработок wineskin + прохаченный winetricks'ом набор библиотек (т.е. некоторые dll подменены на настоящие). Но это не решит всех проблем. Рано или поздно, придется ковыряться в этом наборе из сотен мегабайт исходного кода... Вот скажем, где зарыта бага, ведущая к таким красивым картинкам? Ответ нетривиальный...