LINUX.ORG.RU

wine умеет немного больше или Win32 кросплатформенный api

 , , , ,


0

2

Сегодня случайно открыл для себя что wine это не только запускалка .exe файлов на linux, но также и портированное win32 api.

Наверное, это и так все знают, хотя часто вижу сообщения в духе: «никогда не портируют на linux, так как прибито гвоздями к Win32».

Те кто так думают, знайте, Win32 кросплатформенный api, и нужно всего лишь перекомпилировать.

Нашёл в интернете hello world на Win32 api:

#include <windows.h>

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow)
{
    MSG  msg;    
    WNDCLASSW wc = {0};
    wc.lpszClassName = L"Static Control";
    wc.hInstance     = hInstance;
    wc.hbrBackground = GetSysColorBrush(COLOR_3DFACE);
    wc.lpfnWndProc   = WndProc;
    wc.hCursor       = LoadCursor(0, IDC_ARROW);

  
    RegisterClassW(&wc);
    CreateWindowW(wc.lpszClassName, L"Native App",
                  WS_OVERLAPPEDWINDOW | WS_VISIBLE,
                  100, 100, 330, 270, 0, 0, hInstance, 0);

    while (GetMessage(&msg, NULL, 0, 0)) {
  
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return (int) msg.wParam;
}

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, 
    WPARAM wParam, LPARAM lParam) {

    static wchar_t *lyrics =  L"Hello World!";

    switch(msg) {

        case WM_CREATE:
      
            CreateWindowW(L"Static", lyrics, 
                WS_CHILD | WS_VISIBLE | SS_LEFT,
                20, 20, 300, 230, 
                hwnd, (HMENU) 1, NULL, NULL);
            break;

        case WM_DESTROY:

            PostQuitMessage(0);
            break;
    }

    return DefWindowProcW(hwnd, msg, wParam, lParam);
}

собрал

winegcc main.c -o hello

создалось два файла:

  • hello.exe
  • hello.exe.so

hello.exe это на самом деле баш скрипт:

#!/bin/sh

appname="hello.exe.so"
# determine the application directory
appdir=''
case "$0" in
  */*)
    # $0 contains a path, use it
    appdir=`dirname "$0"`
    ;;
  *)
    # no directory in $0, search in PATH
    saved_ifs=$IFS
    IFS=:
    for d in $PATH
    do
      IFS=$saved_ifs
      if [ -x "$d/$appname" ]; then appdir="$d"; break; fi
    done
    ;;
esac

# figure out the full app path
if [ -n "$appdir" ]; then
    apppath="$appdir/$appname"
    WINEDLLPATH="$appdir:$WINEDLLPATH"
    export WINEDLLPATH
else
    apppath="$appname"
fi

# determine the WINELOADER
if [ ! -x "$WINELOADER" ]; then WINELOADER="wine"; fi

# and try to start the app
exec "$WINELOADER" "$apppath" "$@"

выглядит как-то так: https://i.imgur.com/u6pzVeJ.png

★★★★★

А ещё есть такая штука, Winelib. Имея оригинальные или декомпилированные исходники виндового приложения на руках, можно попытаться собрать нативное приложение под Linux, которое и будет использовать эту библиотеку.

Хотя сделай ldd hello.exe.so, есть подозрение, что тут используется такая же хрень. Ан нет, судя по Shell-портянке там обычный Wine вызывается.

Убогий Shell-костыль да ещё и запуск Wine… представляю, как это всё тормозит на запуске в сравнении с нативненьким ELF.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

У меня на VirtualBox Manjaro 32 bit.

ldd ./hello.exe.so 
	linux-gate.so.1 (0xb7f53000)
	libwine.so.1 => /usr/lib/libwine.so.1 (0xb7d5c000)
	libm.so.6 => /usr/lib/libm.so.6 (0xb7c59000)
	libc.so.6 => /usr/lib/libc.so.6 (0xb7ab3000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0xb7aad000)
	/usr/lib/ld-linux.so.2 (0xb7f55000)

file ./hello.exe.so 
./hello.exe.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=454da947f024d61c0b06a8210739b512e8a76ab6, not stripped
fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от EXL

Нет. Пишет ошибка сегментирования.

Попробовал winemaker, да это похоже для удобства портирования тулза.

Создаёт makefile, в котором

### Tools

CC = winegcc
CXX = wineg++
RC = wrc
AR = ar

дальше несколько правил: clean, .cpp.o: и другие

Плюс может создавать не пустой makefile, а на основе проекта Visual Studio.

fsb4000 ★★★★★
() автор топика
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

Значит я поторопился с перечёркиванием текста в первом посте.

EXL ★★★★★
()

Win32 кросплатформенный api

Но ведь это говно мамонта, простите, а не апи. Зачем его в линух тянуть?

beaver
()
Ответ на: комментарий от beaver

Всё в вантузе до сих пор построено либо на win32 api, либо на схожем native api из ntdll.dll. Всё остальное только говнообёртки сверху.

anonymous
()
Ответ на: комментарий от anonymous

Всё остальное только говнообёртки сверху.

Говнообёртки потому и делают, что базовый апи — ещё большее говно, на котором что-либо писать невыносимо.

beaver
()
Ответ на: комментарий от beaver

Зачем его в линух тянуть?

Просто решил поделиться.

А вариант использования: вдруг есть какое-то приложение от которого

  • есть исходники
  • долго/лень портировать на Linux
  • плохая производительность если запускать wine напрямую.

Я думаю это особенно для всяких arm платок должно помочь. Они же для intel .exe файлов Qemu используют. А тут будет нативный ELF, хоть и с wine.

fsb4000 ★★★★★
() автор топика

mingw-w64 позволяет тоже из под linux компилировать для винды причём полноценно портабельные приложения вообще без зависимостей.

Хотя всё же наверное реализация winapi у вайна будет по лучше (наверное!)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Так это не для винды, это для linux. Вот правильно сравнили, это просто типа тулкита для linux, как qt или x11 или gtk

fsb4000 ★★★★★
() автор топика

Причём всё очень просто

Твой исходник берём и ..

x86_64-w64-mingw32-gcc main.c -lmingw32 -mwindows -o app.exe
wine ./app.exe

https://i.imgur.com/L2vatIQ.png

Вуаля! И не надо пердолиться! А можно собрать всё статически (лицензия позволяет) и просто скопировать исполняемый файл на винду и всё будет работать )

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от fsb4000

Аааа, ну можно и так, если есть исходники вендовые софта под нормальной лицензией, то да это полезно, можно (вероятно это имеет смысл) собирать вайном для вайна или mingw для вайна, и то и то удобно =)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от Harald

Оно некрасивое же всякие lpfnWndProc выглядит и читается как нагромождение символов случайное и так там везде!

Хотя если с детсва, то наверное да, такая чехорда свежей головой воспринимается без проблем наверное

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

lpfnWndProc

в данном конкретном случае читается влёт - указатель на вынь спец. функцию. ожидаю это параметр для передачи callback функции обработчика сообщений. вынь софт не писал 15 лет.

vtVitus ★★★★★
()
Последнее исправление: vtVitus (всего исправлений: 3)
Ответ на: комментарий от vtVitus

Мне просто неприятно такое читать. Понятное дело что это результат принятого стиля именования в API и всё тут. Но фифифи )))) Хотя я даже от SDL ВерБлюЖатиты плююсь, но там ещё терпимо, а тут… хотя наверное я изблован явными_хоть_и_длинными_наименованиями(типа яблоко взять, типа действие кусь); )))

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

выглядит как г, но привыкаешь, всё выглядит единообразно и было достаточно удобно. в линуксячем коде как и всегда кто в лес кто по дрова и это не гуд.

vtVitus ★★★★★
()
Ответ на: комментарий от vtVitus

всё выглядит единообразно и было достаточно удобно

Плюсую, пусть как г, но единообразие решает. Со временем перестаёшь обращать внимание =)

в линуксячем коде как и всегда кто в лес кто по дрова и это не гуд.

Нууууууу, проект проекту рознь. )) Это если на чито API каком писать без вспомогателього всё хорошо, но если API много и они разные то уволь ))) Банальный пример использование SDL + CURL + GTK в одном проекте, как бы ты не хотел будет смешивание и стилей и подходов. По крайней мере в реализации, это если ты сам пишешь библиотеку то оно ладно ты всё спрячешь под своим API, но если у тебя просто приложение будет кокофония всякого. В linux сотни либ с разной спецификой и они часто используются вместе от того и всё вот так и есть. Но в целом взять любой цельный проект то внутри всё более менее хорошо я уже молчу про всякие Гнутые где всё по гнутому или типа nginx который внутри просто лапочка красивая прям сэкас =)

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от beaver

Но ведь это говно мамонта, простите, а не апи.

О, у любителей ломать стандарты раз в два года бомбануло. Это хорошо.

Потому, что это Windows, стабильная десктопная система, где программа, написанная однажды, должна работать всю жизнь. Почитай у Спольски про «лагерь Реймонда Чена». Правда, сам Спольски признавал, что этот лагерь в последние годы начал проигрывать.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Windows, стабильная десктопная система, где программа, написанная однажды, должна работать всю жизнь

Но не работает

Deleted
()
Ответ на: комментарий от hobbit

О, у любителей ломать стандарты раз в два года бомбануло

+

Deleted
()
Ответ на: комментарий от Deleted

Но не работает

достал своё приложение скомпилированное в «июн 11 2002» запустил в wine. Работает. Достал одну из зачОтных работ за 99 год (windows nt4) и тоже работает.

vtVitus ★★★★★
()
Ответ на: комментарий от beaver

Но ведь это говно мамонта, простите, а не апи. Зачем его в линух тянуть?

Не понимаю аргументации за клеймом «говно мамонта». WinAPI постоянно расширялось - просто старые функции не выкидывались, из-за чего куча старых функций является просто обертками над новыми. Ну и вообще, это все-таки больше интерфейсы к функциям ОС, а не прикладная библиотека - а десктопные приложухи у нас на винде довольно много писались.

byko3y ★★★★
()
Ответ на: комментарий от beaver

базовый апи — ещё большее говно, на котором что-либо писать невыносимо.

Мне интересно, что ты скажешь, если узнаешь, что в родном NT API есть форк?

byko3y ★★★★
()
Ответ на: комментарий от beaver

На этот случай уже сделаны обертки без вмешательства мелкософта.

В голову только Qt приходит и VCL.

Так, секунду... то есть, все-таки прыдудущие твои сообщения были про виндовые Common Controls, а не API в целом, что ли? Common Controls - это тупо либа, которая регистрирует в процессе свои классы окон. То есть, грубо говоря, это регистрируется соотношения строки-идентификатора и оконной функции, после чего приложение может по идентификатору класса создать окно кнопки-редактора-выпадающего списка, где весь функционал будет реализован предварительно установленной оконной функцией. Это модель динамической диспетчеризации, которая с минимальными отличиями реализована в Objective C.

Но! Отношения всё это к WinAPI не имеет, оно всё строится уже на базе этого API, используя RegisterClass, GetClassInfo, и функции передачи сообщений окнам (сообщений, которые и обрабатываются оконной функцией).

Соответственно, окошки Qt и VCL, а также MFC работают не на WinAPI, а на WinAPI + Common Controls.

byko3y ★★★★
()
Ответ на: комментарий от CYB3R

А почему бы и нет? Много кроссплатформенного софта на GTK. Вот тот же гимп.

Потому что в GTK плохая поддержка винды, которая делается по остаточному принципу. Потому, например, wxWidgets работает в никсах на GTK+, но на винде использует родные контролы.

byko3y ★★★★
()
Ответ на: комментарий от hobbit

Почитай у Спольски про «лагерь Реймонда Чена». Правда, сам Спольски признавал, что этот лагерь в последние годы начал проигрывать.

Спасибо, почитал. Интересная позиция, но какая-то не законченная, на мой взгляд, потому мне есть что к ней добавить. К слову, может быть сам Джоэл понимал, что лучше об этом не говорить.

Дело в том, что Win API специально сделан поперек остальных систем для реализации vendor lock. То есть, он не просто был несовместим с POSIX - он был анти-POSIX. Канонический пример пример - слэши в другую сторону у путей файла. Много у кого было желание запускать виндовые приложения на невинде - для этого был сделан Wine. Но проблема в том, что в винде есть куча недокументированных возможностей, а большая часть виндового софта имеет кучу отклонений от корректного использовани API (фактически - багов), из-за чего возникали проблемы с созданием win-like API. Но это была борьба со временем, в конце-концов сорцы винды утекли, все недокументированные особенности систем вплоть до Win XP стали публичным достаянием, и время до портирования виндовых приложений начало неумолимо сокращаться, пока не настало время забить последник кол в сердце - запуск офиса на невинде.

Все эти веселые баталии были внезапно остановлены совершенно новой технологией - игрофоны. Маленькие мобильные компьютеры, которые очень нравятся детворе из школ и офисов, стали серьезной силой, которая сравнилась с десктопами по влиянию, хоть в ближайшие 10 лет и близко не сравняются по эффективности труда на них. Теперь в мире стало примерно четыре (4, черт подери, ЧЕТЫРЕ) платформы для пользователей: винда, позиксы (включая макпорты), андроид, айос (с возможностью запустить их в макосе). Что писать? Для кого писать? Кому нужен WinAPI? 3 из 4 платформ не поддерживают WinAPI. Vendor lock исчерпал себя, мелкомягкие более не могут контролировать рынок - он стал им не по зубам. Лагерь реймонда чена проиграл не потому, что это глупые менеджеры так решили, а потому, что вестись на лохотрон по имени «vendor lock» более никто не намерен - именно потому менеджеры поняли, что реймонду пора на пенсию.

И потому IE более не развивается - этот браузер был серьезной фигурой во времена vendor lock, и именно потому плевал на все стандарты и шел вразрез с ними, деля сайты на «IE-only» и «все остальные», таким образом выдавливая те системы, которые не могли поддерживать IE-only-сайты. В какой-то момент MS-у щелкнули по носу конкуренты, выставили большой счет через антимонопольные службы, и сами заняли рынок - теперь майкрософту и вовсе нет смысла разарбатывать свой браузер: последний релиз IE 11 был в 2014 году.

.NET, который изначально разрабатывался как новый vendor-lock для неумолимо устаревающего WinAPI, сыграл немного иную роль, которая возникла именно из-за потери доминирования. .Net был общей платформой для никсов и винды при помощи Mono, когда потребитель не ограничен жестко одной виндой, но при этом использует GUI, который в пользовании приятнее Java-based аналогов. И таки оракл полностью сдал эту нишу, отказавшись от JavaFX. Правда, ниша оказалась не особо перспективной из-за возникновения игрофонов, под которые эта платформа не прокатывает. Да, есть замечатальный ASP.NET - вполне серьезный игрок на рынке, мягко привязывающий вас к винде, хоть и не полностью ограничивающий благодаря Mono.

У MS все еще есть серьезные карты, как то MS Office, который в ближайшее время никуда не уйдет, несмотря на наличие серьезных конкурентов в лице OpenOffice, Google Docs, и прочих. При этом MS сам отпустил свои позиции винды, выпустив Win 10 в том виде, который многим не понравился, но сделано это было вполне нарочно: эта винда не должна быть vendor-lock-ом, который уже не прокатывает, это будет просто еще одна платформа, которая, как андроид, будет стучать о каждом вашем действии в интернет. При этом, есть «Windows Subsystem for Linux», есть линукс-совместимые контейнеры, есть портируемый .NET - мне только не совсем ясно, почему они просят такую большую цену за десятку: от 100$ за самую дешевую лицензию. Та же макось вообще за символическую плату обновляется (порядка 20$). Конечно, они специально оставили лазейку для пользования десяткой вообще без лицензии, но все же - цена за лицензию странная.

Интересно затронуть еще такую тему, как UWP. Дело в том, что MS хотела таки захватить мобильный сегмент, для чего приобрела нокию, а позже создала платформу для десктопов на win 10 и мобилок на win 10 mobile. Получается два зайца одним выстрелом: и покрыли все сегменты устройств, и заставили пользователей уйти с win 7, которая до сих пор остается популярной десктопной осью несмотря на то, что win 10 релизнута в 2015, а последний сервис пак для семерки - в 2011. Но что-то не срослось. Если кто в курсе, почему мобильный сегмент MS провалился - расскажите.

byko3y ★★★★
()
Ответ на: комментарий от Deleted

И не понимаю чем он лучше культей. Qt хоть тему и диалоги родные умеет.

Оно не лучше Qt, оно хуже Qt. На виндовые порты GTK уже давно забили, и поддерживают их для галочки. Попробуй как-нибудь на досуге собрать GTK под виндой, например. Я вот как-то PyGTK пытался под виндой собрать - проморочился день, и забил.

Пользуюсь gajim под виндой: на GTK 2 было еще терпимо, но с GTK 3 интерфейс стал работать просто отвратительно. К сожалению, GTK 2 тоже не прокатывает, потому что неумолимо входят на рынок мониторы высокого разрешения и прочие мелкие плюшки, из-за чего функционала двойки уже не хватает.

byko3y ★★★★
()
Ответ на: комментарий от Deleted

Да, анаконда хороша, подтверждаю. Cython я тоже оттуда брал. Разговор был не об этом, а о том, что GTK слабо поддерживается на винде. Впрочем, как и сам питон - это сможет оценить любой, кто рискнет сделать консольное приложение для винды, поскольку проблема с кодировками консоли в питоне не решена до сих пор, и никого она особо не волнует.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

это сможет оценить любой, кто рискнет сделать консольное приложение для винды

Ну я делал, траблы конечно есть... Но решаются: sys.stdout.reconfigure(encoding='utf-8')

Deleted
()
Ответ на: комментарий от byko3y

Интересное мнение. Правда, статья Спольски, мне кажется, была написана всё же до того, как нашествие мобильных платформ переросло в триумф. Поэтому, возможно, на них и не сделано акцентов. Спольски уверенно подметил другую тенденцию — переход десктопа в Web, что в 2004 году было ещё не так заметно.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Да, я только сейчас заметил, что статье уже 15 лет. Тогда, действительно, она была на острие. С другой стороны, в контексте нынешнего треда это все-таки говно мамонта, имеющее больше историческое значение.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Канонический пример пример - слэши в другую сторону у путей файла.

программисты, которые писали windows, делали это на POSIX системе, поэтому, виндоуз умеет в слеши в обе стороны

next_time ★★★★★
()
Ответ на: комментарий от Deleted

win10 у меня только в виртуалочке, поэтому 2002 нет это 3d приложение. 98 глючит, но запускается.

vtVitus ★★★★★
()
Последнее исправление: vtVitus (всего исправлений: 1)

Тред открывающих для себя winelib и mingw-w64? А ещё cl.exe любой версии можно из под Wine запускать.

a1batross ★★★★★
()

никогда не портируют на linux, так как прибито гвоздями к Win32

AkelPad, например, по этой причине и не портируют — он и так под Wine работает, его даже тестят регулярно вроде.

Но ты особо не обольщайся; если Wayland-фанатики и x86-закапыватели победят, то Wine крышка. Открытый и богатый возможностями по расширению и копанию в чужих окошках Win32 идейно не совместим с огороженностью Wayland, поэтому портировать его не будут — иначе выйдет обгрызенная кака с отвалившимся треем, скриншотами, скринкастами, заданием размеров окна со стороны приложения и пр. Худо-бедно под Xwayland поживёт, пока его не закопают. А про x86, думаю, и объяснять не надо: 64-разрядный Win32-софт — поныне экзотика, ибо зачем, если проге не нужно 3+ ГБ рамы?

anonymous
()
Ответ на: комментарий от byko3y

в GTK плохая поддержка винды

Да ладно, виндузятникам привычны инопланетные приложения с инопланетным UI/UX, схавают. Вон Inkscape популярный весьма, даже при том, что он страдает от глюков GTK+ с неанглийскими локалями. Я на винде Dvdisaster пользую: выглядит страшно, файловый диалог ненативный, но работает, кнопки тыкаются — чего ещё неискушённому юзеру надо?

Вон в популярном хромоге та же фигня, он мало того что системную тему не умеют юзать для всяких там кнопочек, так ещё и шрифты рендерит криво, и это не баг, а фича — он в том числе из-за этого такой шустрый.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.