"Ко-ко-ко-кроссплатформенно" - это больше из разряда интересов студентов и школьников, у которых дома линукс, а домашку надо показывать в классе на венде. В крупной конторе обычно нет проблем купить всем по лицензии виндоуз (или другого ПО), если это потребуется.

@ntsm Лол, это мне для дома нет проблемы купить лицензию (кстати куплена), а для фирмы, где в принципе компьютеры испльзуются для разных нужд, такое вот мероприятие упрётся в отсутствие гибкости венды, в отсутствие вменяемой поддержки, и в конце концов в бюджет.

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

@screwedupcrew > отсутствие гибкости венды, > в отсутствие вменяемой поддержки, чочочочо

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

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

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

@screwedupcrew Надежда на то, что люди как-то сорганизуются запилить софт, который нужен им и их коллегам. На корпорастов надежды нет. А что там гугл делает? Онлайн-хуиту как всегда?

@marune Что мне ваше gtk, когда там .net баг на баге, элсо сколько пользуюсь gtk, никогда ничего не замечал, о каких виджетах речь? Если висит, то значит слабоповторим, или не критичен.

@screwedupcrew Заюзай GTK#. Это лучшее из обоих миров, все баги гтк и дотнета инклудед.

@marune Пока не организуются и не сделают, очевидно же.

@marune Схуяле ты взялась тут прогнозировать что будет? Ванга дохуя?

@marune >Не замечал потому что дурак Аргумент, конечно, скажи ещё, что это у меня руки растут не оттуда. >в любой длинной менюшке Дефайн любая длинная менюшка, что это, листбокс, контейнер со скроллом? >в гаджиме вот наблюдала Если ориентироваться на гаджим, то так можно много новых багов найти, настолько они правда будут относиться к библиотекам, а не к собственно гаджиму, вопрос. >пока вы будете твердить что корпорасты зло, не делают нам опенсорс Я даже не твержу, я просто смеюсь над тем, как они теряют свою прибыль, а также будущее, производя некросплатформенные решения

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

@marune В 2008 закрыли же.

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

Лично для меня это проблема тестирования. Тоже хочется, чтоб и Linux, и Solaris, и Mac OS X разных архитектур и версий, но то говно, которое есть в качестве компьютера, астрономически далеко от этих желаний. Кроссплатформенная же компиляция в неразвитом состоянии. Вот я помню, взять Watcom. Три таргета: DOS4GW, OS/2, Win32, и с каждого можно собрать на любой другой. А как бы мне с моей Mac OS X 10.4 попроще покомпилировать под Solaris? Эту проблему интересно наблюдать на плагинах. Среди программ бывают кроссплатформенные, вроде iTunes, Safari, и к ним есть плагины. А ещё есть Mozilla Firefox. Для него плагинов с нативным кодом гораздо меньше, но они тоже есть, и я вижу, что, даже, если разработчики поднапряглись и сделали версии под разные OS, то разработчики плагинов так напрячься в общем случае не смогли, и плагины некроссплатформенные. Вот для Safari есть куча интересных плагинов, но только под Mac OS X. Для iTunes был multi-plugin, но только для Windows. А те плагины, которые самые кроссплатформенные, на JavaScript, на Python, в общем, ненативные. Лично мне решение видится в том, чтобы создать единую бинарную платформу, как у Java, только бинарную. Сейчас такая платформа мне известна только одна: Wine. Нужно перестать воспринимать Wine как эмулятор Win32api и средствами Winelib сделать так, чтобы exe'шники первым делом определяли OS, в которой они работают, подгружали OS-зависимые libuv.dll.dylib на Mac OS X или libuv.so.dylib на Solaris или libuv.dll на Windows, и, используя OS-зависимые версии библиотек, забывали бы о своих виндовых корнях. О работах в этом направлении мне пока не известно.

@marune Предложи альтернативы. Я долго болел за OpenLINA. Пока я за него болел, Wine жил и здравствовал, и жить и здравствовать продолжает

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

@marune Вот вышел Leechcraft, для Leechcraft есть самый важный плагин Leechcraft-EiskaltDC. Все из себя такие кроссплатформенные, на Qt. Как же мне их запустить на моей Mac OS X? Компиляцию не предлагать.

@octagram >Компиляцию не предлагать. Почему нет?

@goren Потому что разработчик не скомпилировал, а я, что, за него это должен делать? Потому что не компилируется без рашпиля, это два.

@octagram Почему за него? Кому надо, чтобы эта хуйня запустилась на $OSNAME, тебе или ему? Ну ставь тогда условие не "без компиляции", а "без напильника".

@marune Так я этого и хочу. Просто Java и .NET несколько опорочили идею кроссплатформенности своими унылыми ограничениями, а wine в сочетании с winelib'ами кажется мне тем, что доктор прописал.

@marune Да нет. Компилируем один раз как бы под Windows, но с обильным использованием OS–зависимых библиотек. Полчуается всего лишь один бинарник. И каждый плагин — это один бинарник. Он либо есть, и работает теоретически везде, либо нет. Если где–то не работает практически, это уже проблема тестирования, а не портирования

@octagram А у .NET кстати подобная описываемая тобой затея, всё в сборочках, подгружаются те сборочки, какую ОС используешь. Только что mono не всё реализует хорошо, но в общем-то лучше, чем дела у wine.

@screwedupcrew Только alloca() нет в Mono и многих других само собой разумеющихся на реальном CPU вещей. И мало языков портированы, а те, что портированы, скорее всего, не проверялись на совместимость. То есть, если библиотека на C++, сишный адаптер к ней и адская обёртка к сишному адаптеру плюсовой библиотеки, то я сильно сомневаюсь, что C++/CLI и Ada для .NET сходу дадут такой же результат, как в нативе. А если компилировать как бы в Windows, то тут уже всё работает.

@octagram Дак оставим же неуправляемый C++ геймдевелоперам, всё остальное с современной производительностью летит и на управляемом коде.

@marune Если развивать такую платформу, то каждый юзер Solaris, Mac OS X, FreeBSD и других непопулярных таргетов Wine будет работать на то, чтобы увеличить популярность этих программ

@marune Пока ребята из Вилларибо пытаются скомпилировать каждую программу и каждый плагин к ней под каждую OS, ребята из Виллабаджо уже всё скомпилировали под Wine

@octagram И объбались об недореализованные затычки в вызовах, хах. Ладно, твоя идея понятна, но почему за основу взят wine, реализация не самого красивого (уёбищного?) api, может лучше виндозятники будут всё компилировать под цыгвин? Так ведь проще, у юникс-подобных ОС простой интерфейс.

@screwedupcrew Я предлагаю забыть о виндовых корнях, и об этом API тоже, а использовать другой устоявшийся API, такой, как у libuv, sdl и т. п., а во время работы подгружать нужную версию этих библиотек

@octagram А, ну sdl ок, теперь понял тебя.

@octagram Не называй решением проблемы кроссплатформенности x86-only хуйню, позязя.

@screwedupcrew У Wine и Cygwin есть небезынтересные доки на тему, как они эмулируют один API поверх другого. Я их почитал, и прихожу к выводу, что WinAPI на POSIX эмулировать проще, чем POSIX на Win32. Самая большая проблема — это fork(), черезчур популярный среди разработчиков под POSIX. Под Windows 7 он может просто рандомно отказывать, потому что Windows уже разместила свои билиотеки по тем адресам, где в форкающемся процессе было что–то другое. В Win32 самая большая проблема — это неперемещаемые exe'шники без таблицы relocations

@stiletto Под не–x86, наверное, может сложиться что–другое. В конце концов, под Linux есть qemu-user

@octagram >qemu-user ты предлагаешь мне через ЭТО пускать x86-приложения на и без того хиленьких армах?

@stiletto Ну это гораздо лучше, чем ничего. Проблема–то не в том, что абстрактный Leechcraft-EiskaltDC работает на Mac OS X медленно. Проблема в том, что он не работает вообще никак, его просто нет. При том, что архитектура CPU не отличается. Есть Google Portable Native Client, но под него ещё нет компиляторов

@octagram но qemu это не "медленно", это "абсолютно неюзабельно" даже при эмуляции x86 на x86 (без kqemu и kvm)

@stiletto qemu или qemu-user?

@octagram оба

@stiletto Скоро посмотрю эмуляцию x86_64 на x86 в qemu-user. Пока что видел только Turbo Pascal на Android, вроде нормально