LINUX.ORG.RU
ФорумTalks

У кого есть опыт использования Wine не как системы имитации вендового окружения для вендового софта, а как нативной гуёвой библиотеки?

 


0

3

Что-то задолбали эти постоянные изменения в Qt/Gtk. Из-за этого Win32 выглядит намного предпочтительнее, хотя и является отстоем.

Нужно чтобы гарантированно в ближайшие 20-30 лет никаких изменений в API не было и в любом дистре оно было искаропки.

Можно, конечно, каое-нибудь древнее GTK2 взять, но где гарантия что его не выкинут из всех дистров через пару лет? Вот Wine не выкинут, а GTK2 запросто.

Xlib сгодилась бы, но там толком нет виджетов, к большому моему сожалению.

Собственно, по-сути, из Win32 нужны только виджеты - всякие там кнопки/выпадалки/Treeview/ListView/OpenFile/etc. Никаких CreateFile, EnterCriticalSection или прочей параши не требуется.

Win32 ещё хорош тем, что не надо в венду тащить тонну чужих либ. От венды отказаться пока не получится, т.к. предприятия не торопятся отказываться от венды и иногда даже WinXP попадается. Хорошо, конечно, если что-то внезапное случится и венда сдохнет через годик как явление, но всерьёз на это закладываться я не стану.

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

★★★★★

Последнее исправление: Stanson (всего исправлений: 2)

Нужно чтобы гарантированно в ближайшие 20-30 лет никаких изменений в API не было в любом дистре оно было искаропки.

tcl/tk подходит идеально.

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

Нет, и не собираюсь. Паскаль, к сожалению, практически умер. Однако, если бы в GCC был компилятор паскаля, а все основные линуксячьи либы (включая гуйню) имели бы паскалевые биндинги, то было бы здорово.

Штуки вроде Lazarus - это всё-таки неправильно, не UNIX-way.

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

Графический тулкит в wine довольно медленный и сильно завязан на его внутреннее устройство. Откртие окна и отрисовка происходит поверх драйверов вроде winex11, переделать туткиты без этого довольно сложно. Сама же разработка wine давно ушла с пути unix-библиотеки и он сейчас все бинари собирает в dll и работает уже фактически на уровне сисколов, когда unix часть притворяется ядром, а юзерспейс целиком виндовый
Если нужен прямо виндовый тулкит - есть смысл взять libgdiplus, который под линуксы реализован в составе mono. Тогда у тебя будет доступно одно и тоже api как под windows с оригинальным gdiplus, так и на системах, где работает libgdiplus от mono. Поддержки wayland, правда. нет, потому оно будет рисоваться через xwayland там, где нет иксов.

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

Мне подход lazarus в целом нравится кроме одного момента - там паскаль XD

mittorn ★★★★★
()

Нужно чтобы гарантированно в ближайшие 20-30 лет никаких изменений в API не было в любом дистре оно было искаропки.

Motif

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

на венду его таскать

Таскайте венде цветы на могилку. Самое лучшее, что можно тут сделать.

ugoday ★★★★★
()

на винфак

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

Графический тулкит в wine довольно медленный и сильно завязан на его внутреннее устройство.

Я в курсе как устроен wine, я для него даже всякое нетривиальное портирую, типа https://github.com/stanson-ch/libusb-wine-ng

переделать туткиты без этого довольно сложно.

Ну тулкит переделывать мне не требуется.

Сама же разработка wine давно ушла с пути unix-библиотеки и он сейчас все бинари собирает в dll и работает уже фактически на уровне сисколов, когда unix часть притворяется ядром, а юзерспейс целиком виндовый

Примерно так, да, winex11.so за гуйню отвечает, а user32, kernel32, gdi32 и commctl32 - вендовые DLL которые дёргают линуксовую winex11.so. Но никто ведь не мешает собрать их как линуксовые либы. Ну будут нативные user32.so, kernel32.so gdi32.so и commctl32.so. Большего для полноценной гуйни и не требуется.

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

Интересно было бы даже написать какой-нибудь Makefile с патчиками для wine чтобы собирал какую-нибудь libwin32.so из сырцов Wine.

есть смысл взять libgdiplus, который под линуксы реализован в составе mono.

gdiplus не нужен, нужна исключительно win32. GDI+ нету полноценного на XP например, ЕМНИП. Да и mono не во всех дистрах искаропки. А главное - в GDI+ нет всех этих виджетов. Это же только низкоуровневая графика.

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

нету полноценного на XP

а кого это волнует в 2026? На рандомной инсталляции десятки он присутствует
А виджеты уже можно и поверх реализовать

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

а кого это волнует в 2026?

Меня.

А виджеты уже можно и поверх реализовать

Делать мне больше нехрен.

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

Меня.

ну поставишь нетфреймворк на xp, gdiplus там появится

Делать мне больше нехрен.

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

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

тебе явно хочется странного - чтобы софт без сторонних библиотек работал и на xp и под современными дистрами.

Он и так работает. Просто не хочется пускать вендовую софтину под Wine.

Наверно это всё-таки потребует какой-то доработки существующего инструментария. Не хочешь gdiplus - бери SDL и рисуй кнопочки сам

Ещё раз - как раз кнопочки и прочие контролы мне и нужны из win32.

У меня есть (была) версия с Qt, но все эти Qt4->Qt5->Qt6 достали и я её бросил. Кроме того, в том же Qt несколько геморройнее делать всякие нестандартные штуки с виджетами, которые в win32 делаются через всякие *_OWNERDRAW, например. Можно, но больше писанины и стабильности.

Win32 - лютое говно, на самом деле, но зато стабильное. Микрософт конечно старается насрать (типа отменённого мультивыбора в TreeView в win10 и старше), но т.к. win32 считается не модным, они, к счастью, туда редко гадят.

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

Должен - не значит есть.

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

сейчас вооружатся llm'кой и изгадят оставшееся во имя безопасности

mittorn ★★★★★
()

Нужно чтобы гарантированно в ближайшие 20-30 лет никаких изменений в API не было в любом дистре оно было искаропки.

Пиши на сразу на electron.

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

Те 30 лет, когда могли не ломать апишку тулкита уже прошли

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

К сожалению, реакция «блеванул», единственная подходящая к такому предложению, на ЛОРе отсутствует.

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

А нельзя разве весь нужный рантайм с дистрибутивом проги распространять? Тут же такое дело: ты либо пилишь какой-то апп для прода, который на древних системах, и тогда любишь старый API той версии тулкита, который на этих системах идёт в рамках дозволенных обновлений. Либо, ты пилишь опенсорс, ты в тренде современных реалий гуестроения, и ты любишь немного переписывать софт под меняющиеся версии фреймворков.

Так, что и стабильно, и всегда современно - такого не бывает. А если про Винду речь, то на чистом winapi гуи никто в трезвом уме не пишет.

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

А нельзя разве весь нужный рантайм с дистрибутивом проги распространять?

Не хочется связываться с решением проблем с работой этого рантайма, особенно на венде. Это раз. Не хочется постоянно переписывать свой софт при выходе новых версий этого рантайма. Это два.

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

Я пилю самодостаточную проприетарщину которая обязана гарантированно работать на любых версиях венды начиная с XP и на любых дистрах линукса.

С опенсорсом вообще таких проблем нет - тебе надо - ты и собирай под свою систему.

Так, что и стабильно, и всегда современно - такого не бывает.

Ну у меня же есть. Работает на всех версиях венды начиная с XP, и на всех дистрах но, к сожалению, под Wine.

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

А если про Винду речь, то на чистом winapi гуи никто в трезвом уме не пишет.

Я пишу. Потому что кроме чистого winapi всё остальное что высрал микрософт для своего поделия - ещё более ублюдочное дерьмо. Все эти GDI+ и далее - срань намного хуже winapi. Да к тому же намного хуже документированная и исследованная на предмет багов и косяков. Win32 прост, компактен, все баги и косяки известны и на нём несложно писать так, что будет работать на любой версии венды. А ещё он достаточно шустр, если правильно его готовить.

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

Когда-то писал на Fortran 90 под винду, залез в win32 и написал смотрелку фрактала. Это был конец 90-х. Спустя много лет проверил - работает под вайном в режиме 10-й винды, только русские шрифты кое-где глючат. Почти 30 лет получается.

Так что может вин32 относительно стабильная штуковина.

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

Не хочется постоянно переписывать свой софт при выходе новых версий этого рантайма. Это два

Кхм… А вот это вот зачем? Я просто вижу два довольно разных посыла: 1) желание иметь рантайм, который работает всегда, и потому обоснованный страх, что в новой версии дистрибутива Линукс фреймворк xyz выкинут; 2) идти на поводу у этого страха и переписывать софт с каждой новой мажорной версией фреймворка.

Но, во-первых, если это системы в проде, которые должны работать супер-стабильно на устоявшемся системном софте, то и ОС никто не будет обновлять с каждой новой версией этой ОС.

А во-вторых, даже если понадобится что-то переписывать из-за изменений в фреймворке, происходить это будет очень редко, мягко говоря, не с каждым релизом ОС и фреймворка.

А чтобы сценарий «разраба сбил поезд, а больше никто не знает, как система работает и как её править» не поставил работу конторы раком, надо просто писать внутреннюю документацию и/или готовить себе замену на случай отпуска или иного вынужденного отсутствия.

КМК.

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

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

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

Вот поэтому и хочется иметь этот немудрёный гуёвый API под линуксом нативно, а не через Wine.

Собственно, написать прослойку gdi32 + часть user32 где event loop и чисто окошки -> Xlib не проблема вообще, там всё почти один-в-один совпадает. А вот писать контролы из user32 + commctl32 вообще что-то как-то лениво. Там один TreeView можно год писать, чтобы все глюки и баги повторить. Но, к счастью, все эти контролы уже написаны в Wine, причём достаточно точно.

Кроме того, в ранние годы Wine, у него вообще была полуофициальная фича - «собрать вендовые сырцы в нативный линуксовый бинарник». Но сейчас, особенно после реализации wow64 (и, соответственно решения проблемы с multilib для запуска 32-битных софтин) в Wine это стало делать затруднительно, хотя я уверен что это всё-же возможно.

Вот я и решил узнать, может кто такой возможностью пользуется и поделится опытом.

Софтина использует из win32 только гуй, а всё остальное - POSIX, без гуёвой головы без проблем собирается под линукс. Да и с нативной Qt’шной гуйнёй тоже собиралась пока не забросил. Небольшие кусочки с тредами и т.п. легко лечатся при помощи препроцессора.

Необходимость вендовой версии присутствует потому что часто софтина должна работать в паре с железкой, для которой управляющий софт и драйвера существуют только под ту же WinXP. Софтина в виртуалке не работает, или работает глюкаво. Ставить второй комп рядом - идиотизм.

Необходимость линуксовой версии присутствует потому, что уже заметное количество предприятий предпочитают линукс. Иногда даже это первый вопрос - «под линуксом работает?». Ну да, работает, без малейших проблем. Но под Wine. Клиент доволен, его всё устраивает. Но мне это не нравится. Перфекционизмом страдаю, да.

Так что гипотетическая линуксячья libwin32.so реализующая win32 гуйню собираемая из сырцов Wine полностью решила бы проблему.

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

без гуёвой головы без проблем собирается под линукс.

А она вообще нужна, эта голова? Может оставить только консольный интерфейс?

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

Кхм… А вот это вот зачем?

Потому что это мартышкин труд.

А чтобы сценарий «разраба сбил поезд, а больше никто не знает, как система работает и как её править» не поставил работу конторы раком, надо просто писать внутреннюю документацию и/или готовить себе замену на случай отпуска или иного вынужденного отсутствия.

Гуёвый код там вообще ни разу не мудрёный. Так что любой кто знает win32 без проблем разберётся.

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

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

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

И это не только проблема РФ. Во всём мире, по-сути, есть всего 4 ядра для этих задач. 3 западных одно наше. 2 западных уже остались без разработчиков, которые что-то в этом реально понимают, третье продано Конике и разработчики вот-вот уйдут на пенсию. Коника уже просрала одно ядро, потому и решила купить это, но и его просрёт тоже. Ну и мы в РФ нарядные такие теперь.

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

А она вообще нужна, эта голова?

Да, очень нужна. Без неё никак не получится работать. Безголовую версию получится использовать только после создания нужного датасета в полноценной версии.

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

Так что гипотетическая линуксячья libwin32.so реализующая win32 гуйню собираемая из сырцов Wine полностью решила бы проблему.

В итоге у тебя win32-программа превратится в linux-app с обвязкой wine, и ты придешь снова к тому же, откуда начинал: «Нужно чтобы гарантированно в ближайшие 20-30 лет никаких изменений в API не было и в любом дистре оно было искаропки.»

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

В итоге у тебя win32-программа превратится в linux-app с обвязкой wine

Ну да. Только не нужны будут всякие wineserver и пр. которые запускаются при запуске через wine и которые нафиг не нужны для гуя, не нужны будут wine’вские прокладки для устройств и т.п.

и ты придешь снова к тому же, откуда начинал

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

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

С Qt можно собрать статично, если вопрос в поддержке дистров.

А ещё можно заюзать безбиблиотечный тулкит, JUCE например. Наверняка и другие есть.

kott ★★★★★
()

Нужно чтобы гарантированно в ближайшие 20-30 лет никаких изменений в API не было и в любом дистре оно было искаропки.

Пиши сразу под DOS. Dosbox всегда портируют на любое железо, ради игорь, а графический тулкит ты сможешь сделать сам руками, и всё упаковать в один-единственный .exe-шник. Вот тут, пожалуй, можно гарантировать, что у тебя и через 30 лет всё будет работать на любой бо-меее общеупотребительной ОС.

Вот Wine не выкинут,

ой, я не был бы так уверен. С другой стороны, никто не мешает писать под ХР-шечку, с оглядкой на вайн. Уж виртуалки-то тоже, всегда будут существовать, а виртуалка с ХР-шечкой по нынешним временам жрёт очень мало ресурсов.

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

это будет очень редко, мягко говоря, не с каждым релизом ОС и фреймворка.

Буквально Qt при переходе от 5й к шестой версии переименовали половину enum'ов и неймспаейсов. Why?

BECAUSE REASONS, YOU KNOW~

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

С Qt можно собрать статично, если вопрос в поддержке дистров.

Статично не можно, ибо проприетарщина. А динамично - тащить с собой на венду почти весь Qt.

безбиблиотечный тулкит, JUCE например

Тоже не можно, ибо софтина - проприетарщина. По крайней мере на ближайшее десятилетие. Когда весь рынок РФ окучим, скорее всего выложим сырцы под GPL чтобы убить все западные аналоги которые X-Rite и Konica-Minolta продают за десятки тысяч баксов. Ибо нехер было всякие сракции соблюдать.

А гуёвый тулкит есть уже - win32. Реализованный на обоих системах. Вопрос только об удобстве его использования на линуксе.

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

Мне нахер не нужен растеризатор и пр. я сам себе растеризатор. Уж нарисовать графику в памяти и блитнуть картинку на экран средствами системы вообще не проблема с любым тулкитом и на любой системе. Всякие LineTo и Ellipse меня не интересуют. Мне нужны виджеты/контролы. Всякие TreeView и Combobox’ы, причём не менее фичастые чем в венде или кутях.

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

в imgui контролы есть. Насчёт фичастости правда не знаю - они весьма спецефичные

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

delphi
Паскаль, к сожалению, практически умер

Ну есть/был C++ Builder.. те же дельфи, только C++

Bad_ptr ★★★★★
()

Ну а так то надо просто гуй делать на html/js под IE6 а сама прога запускается как сервер

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

все эти Qt4->Qt5->Qt6 достали и я её бросил.

А если взять какую-нибудь одну версию Qt (или другой более простой в употреблении gui-библиотеки) и собирать свою программу с ней статически? Я бы сказал что api Иксов достаточно стабильно чтобы на него можно было расчитывать(либо на его эмуляцию). Чем меньше зависимостей от чужих динамических библиотек тем меньше шансов что что-то сломается.

watchcat382 ★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)