Открытое и свободное

Перевод, оригинал находится здесь

Здесь представлены несколько общим “мифов” о Wine, которые или полностью ложны или не совсем корректны.

Миф 1: “Wine медленный, потому что является эмулятором”

Некоторые люди обозначают этим определением то, что Wine должен эмулировать каждую процессорную инструкцию Windows-приложения. Это просто неверно. Даже аббревиатура Wine расшифровывается как “Wine - это не эмулятор”. Wine не эмулирует Intel x86 процессор. Тем самым, это не будет настолько медленно как Wabi, которая не запускается на процессоре Intel x86, хотя и эмулирует этот процессор. Windows-приложения, которые не производят системные выховы, будут работать с той же скорость как и в Windows (ни больше ни меньше).

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

Также люди обычно интересуются, является ли комбинация Windows+Unix более эффективной чем Windows. Это просто зависит от того насколько хороши/плохи их соответствующие алгоритмы. Если быть откровенными, то производительность не является приоритетом Wine. Сейчас гораздо более важным является увеличение количества приложений, могущих работать под Wine. Например, большинство программ измерения производительности пока в Wine не работают, и заставить их работать так, как они должны, очевидно более важно чем заставить их просто быстро выполняться.

Но для тех приложений, которые работают, с чисто субъективной точки зрения, обеспечивается хорошая производительность. Здесь нет очевидных потерь скорости, исключая некоторую медленную графику, должно быть из-за неоптимизированного кода Wine и X11, приводящую все-таки к потерям производительности (хотя они могут быть временными)

Миф 2: “Wine вреден для Linux”

Один нескрываемый факт существует: это относится к подавляющему числу программных библиотек, работающих с операционными системами Microsoft. Многие из этих приложений уже имеют Linux-эквиваленты, однако для большинства людей они остаются связывающими руки программами, держащими их прикованными к Windows. У некоторых из этих программ практически нет шансов быть портированными под Linux (например, Microsoft Office), другие не могут быть портированы поскольку от их поддержки отказались (например, TurboTax 1999). Должен ли я хотеть иметь Windows только потому, что когда-нибудь мне может потребоваться доступ к этой старой налоговой программе?

Тот факт, что Wine не помешает компаниям портировать их программное обеспечение, имеющее меньше нескольких процентов на рынке. Wine отдаст большое число свободных программ в руки людей, которые могли бы иначе не использовать их. История постоянно показывает, что большая доля рынка приводит к более коммерциализированной разработке. Более коммерциализированная разработка всегда приведет к попыткам разработать лучшие эквиваленты для свободных программ.

Миф 3: “Эмуляторы наподобие VMWare лучше”

Уверены что они лучше… если вам нравится идея купить полную копию операционной системы только для того, чтобы запустить ее под виртуальной машиной. Не упоминая того что вам потребуется купить копию VMWare чтобы заставить ее работать.

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

Однако, пробовавшие говорят, что есть моменты, когда эмуляторы довольно полезны. Разработчики могут создавать песочницы, в которых и запускать приложения, тестировать другие операционные системы без перезагрузки и так далее. Но иметь полномасштабный эмулятор только для того чтобы запускать в нем текстовой процессор возможно не лучшее решение.

Миф 4: “Вам все равно нужна Windows”

Нет. Целью Wine является полная реализация Windows API, которая сделает Windows ненужной.

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

Миф 5: “Wine плохой, Winelib лучше”

Это, кажется, самый популярный миф на Слэшдоте. Просто некоторые люди думают, что запуск обыкновенного Windows-приложение с Wine намного менее надежен и намного менее производителен чем перекомпиляция того же самого приложения с Winelib. Возможно это вариант мифа о том что “Wine медленный потому что он эмулятор”

Причин для этого на самом деле нет. Для начала, я не обнаруживаю различий в производительности между Wine и Winelib для (хотя для нескольких их признаю) приложений, которые я тестировал в Winelib. Кроме того, вы должны осознать, что ошибки не в способе Wine интерпретировать PE, т.е. формат исполняемых файлов Windows, программы. Ошибки, как и проблемы с производительностью происходят от реализации Windows API, и проявляются в обоих случаях.

Миф 6: “Wine всегда будет играть в догонялки с Windows и невозможно будет успешно запускать новые приложения”

Архитектура Wine делает добавление новых API (или DLL) очень простой. Разработчики Wine быстро добавляют новые функции как только они потребуеются, даже приложения, требующие последнюю функциональность обычно отчитываются о работе спустя несколько месяцев после выхода. Для примера можно привести Office XP и Max Payne (игра, требующая DirectX 8.0) - обе программы были совсем свежими в момент когда это писалось (5/2002).

И в дополнение, Wine поддерживает использование родных DLL, когда встроенные версии не функционируют правильно. Во многих случаях возможно использовать родные версии DLL для предоставления доступа к 100% функций, требуемых приложению.

Миф 7: “Так как Wine может выполнять лишь небольшой процент Windows API, он всегда будет ерундой”

API подобны библиотеке - всегда хорошо иметь настолько много книг на полках, насколько это только возможно, но в реальности потребность в некотором наборе книг будет присутствовать снова и снова. Большинство приложений приводится к небольшому общему знаменателю в случае существования наиболее широкой аудитории. Windows XP поддерживает не просто важнейшие - а почти все приложения, которые могли потребовать Windows 95 или Windows 98. Сейчас Wine поддерживает более 90% вызовов, найденных в популярных спецификациях Windows, таких как ECMA-234 и Open32. И в Wine добавляют еще Win32 API, хотя основная работа сейчас предполагает исправление существующих функций и проведение архитектурных изменений.

Миф 8: “Wine только для Windows 3.1 / Wine никогда не будет поддерживать Win64″

Проект Wine начинался в те времена, когда даже Windows 95 еще не было. И хотя Windows NT (и, следовательно, Win32 API) уже существовала, он поддерживал только приложения Windows 3.1. В любом случае, Windows NT тогда почти никто не использовал.

Но эти дни остались далеко позади. Начиная с августа 2005 Wine представил свою версию реализации Windows 2000, за несколько лет до этого это была Windows 98, так что на самом деле Win32 - это та вещь, которую Wine поддерживает. Поддержка приложений Windows 3.1 также существует, как и некоторая поддержка DOS приложений.

Поддержка Win64 должна позволить Wine запускать родные исполняемые файлы 64-битной Windows, и на февраль 2006 года Wine пока что не может этого делать. Но все в порядке, потому что сейчас доступно лишь очень немного коммерческих приложений Win64. За одним исключением, Unreal Tournament 2004 доступен в родной 64-битной версии под Linux, поэтому никому (ну может за исключением хакеров) не придется запускать под этой версией Windows что-нибудь.

Это не означает, что Wine не будет работать на 64-битных системах. Это есть. Смотрите этот раздел в Wine Wiki для более подробной информации.

Миф 9: “Wine существует только под Linux”

Это попросту некорректно. Ну да, сейчас Wine не запускается на многих платформах: только на Linux, FreeBSD и Solaris. Еще это не “только Linux”

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

Есть также проект по совместимости с Win32 для OS/2 (Odin), который практикует использование кода Wine.

Миф 10: “Wine только для процессоров Intel x86″

Правда, что Wine запускается только на процессорах x86 от Intel. К сожалению.от нас потребуется большое количество работы прежде чем он сможет работать на процессорах других архитектур.

Но что мы представляем, когда говорим “запускается на не-x86 процессоре”

Во первых, это обознчает, “я могу скомпилировать Windows-приложение на Spark, собрать его с Winelib и запускать из-под Solaris”. Я знаю, это не то, что вы думали. Это может казаться очень ограниченным и пока еще не очень полезным: это обозначает легкость переноса Windows-приложений почти на любую Unix-архитектуру. В любом случае это первый шаг к способности Wine работать на других процессорных архитектурах. К сожалению, код Wine не очень портируем на другие процессорные архитектуры, частично потому что некоторые части его знают много о процессоре, частично из-за того, что он делает проверки наподобие ’sizeof(int)==sizeof(pointer)’ и ‘byte-sex==little-endian’. Мы работаем над этим, хотя прооцесс движется слишком медленно.

Еще мы могли бы определитьь, что это обозначает “Wine на Alpha должен быть способен запускать приложения Windows NT Alpha”. Предпосылкой для этого служит то, что Winelib компилируется на Alpha (или MIPS, другой забытой Windows NT платформе). Может ли это быть полезным сейчас? Я не думаю что у многих людей есть приложения Windows NT под процессоры Alpha и MIPS. Так как это возможно и не так полезна и даже маловероятна необходимость программисту выбрать именно эту комбинацию программного и аппаратного обеспечения и работать на ней.

Поэтому это то, чего ждет каждый: “Я хочу запускать мои x86 Windows приложения на любой архитектуре процессора, которая мне понравится”. Это более комплексно. И снова предпосылкой должно быть то, чтобы Winelib работал на архитектуре, которая существует сегодня. Тогда “все что нужно” - это интегрировать эмулятор x86 в Wine (и заодно изменить имя Wine :-). Улрич Вейганд (Ulrich Weigand) сделал это ради эксперимента некоторое время назад, когда у него выдалось “немного свободного времени”. Он даже смог заставить запуститься некоторые приложения Win16. Его код не был еще доведен до состояния, когда он мог бы быть включен в Wine, и я не знаю, как много работы потребуется выполнить, чтобы произвести эту операцию.Хотя его попытка привела к большому числу дискуссий в списке рассылки Wine. В результате мы могли бы получить сложный эмулятор, поддерживающий компиляцию на лету для получения чего-нибудь более-менее жизнеспособного (т.е. не слишком медленного). И разработка такого эмулятора это еще целый проект.
Означает ли это, что такого никогда не будет? Не уверен. Может быть, однажды у нас появятся несколько мотивированных разработчиков, которую решат проблемы с Winelib. Конечно, можно было бы сделать это быстрее, если бы, к примеру, Compaq открыл бы исходники своего эмулятора Fx32! для процессоров Intel x86 и профинансировал бы разработку Wine для своих Alpha машин. Как и со всеми проектами открытых исходников, если достаточное количество людей заинтересованы и вместе привлекают свои ресурсы, то это случится.

Миф 11: “Моя игра содержит защиту от копирования, которая не работает с Wine”

Сейчас SecuRom работает в Wine, и поддержка объектов директорий была добавлена для получения нами реализации ntoskrnl.exe, который позволит загружать драйверы защиты от копирования наподобие Safedisc. Однажды реализованное в Wine ntoskrnl.exe будет обладать полной поддержкой Safedisc версий 1 и 2.