Суть WordPad в том, что он использует системную библиотеку для работы с форматированным текстом (riched32.dl). Это такая же история, как с Internet Explorer — который использует системную mshtml.dll для отрисовки html. WordPad и IE это просто оболочки, а сами технологии из системы не выпилить, потому что есть множество программ, которых их используют.
wine это программа на C, которая может быть собрана под любую архитектуру. В частности, имеется поддержка aarch64 (ARMv8). Несовместимость возникает, когда вы хотите запустить готовый EXE-файл. Тут wine должен быть собран под ту же архитектуру, что и EXE-файл. То есть без эмуляции запустить x86 бинарник на ARM не получится. А вот собрать и своё приложение и wine под ARM получится вполне.
Не очень понял, в чём я ошибаюсь. WinAPI к ненативным GUI не имеет отношения, потому что они делаются вопреки (или же перпендикулярно) механизмам, предоставляемым WinAPI.
Ну вот я привожу Borland в пример, как явление, позволившее обеспечить масовую разработку софта для Windows, без ужасов WinAPI, а вы мне его же приводите в пример про кроссплатформенные приложения. Достоинства решений Borland лишь подчёркивают нищету WinAPI, а не являются следствием полезности WinAPI. И то, что там смогли сделать кроссплатформенность, к WinAPI никакого отношения не имеет.
В Винде нельзя быстро и удобно использовать нативный GUI. Это не быстро и не удобно. А .NET далеко не обёртка, слишком многое там сделано внутри, без перехода на unsafe code.
Вы вот вроде как утверждаете, что нет однородного API в Маке и Андроид, что там «меняется многое, как и в винде. Разные версии апи». Оно там меняется и есть разные версии апи. В WInAPI никаких версий API нет. Вы бы видели эти функции WinAPI, у которых порядок аргументов зависит от версии Windows. Ещё раз, сравнивая с Андроид, где у вас есть возможность собираться с апи разных версий: в Windows ваше приложение обречено на линковку с ABI неизвестных версий, и это ключевая разница. Про то, что «никогда не было проблем в Windows со сторонними библиотеками», не то, что бы это враньё, но не могу согласиться. Microsoft всегда вела себя так, как будто таких библиотек не существует. И да, вы верно заметили, устроила так, что эти библиотеки — головная боль разработчиков. А хотелось бы без головной боли. Например, vcpkg или что-то подобное.
Про MacOS и Android это был пример более стройного и однородного API. Понятно, что невозможно написать приложение без привязки к системе невозможно. Но только на WinAPI никто GUI-приложения не пишет. Это либо было MFC (которое умерло при первой возможности, когда стало возможным перейти на .NET), либо популярные разработки от Borland (библиотеки которых реализованы в стиле борьбы с трудностями WinAPI, то есть предоставляющие разработчикам то, что быть получено штатными средствами системы). И как хорошо, что плюсовые библиотеки не всем нужны. Оказывается, уже можно не писать на C++. Достаточно .NET и требовать всего лишь обновления .NET Framework до 4.8.x, чтобы ваша программа запустилась. В общем, стремление предоставить в API все сервисы (включая формирование электронных писем) это не для удобства программиста, это для того, чтобы привязать пользователей и разработчиков к своей системе. Привязать в плохом смысле. Десятилетия для Windows использование сторонних библиотек было проблемой — их откуда-то качали, куда-то клали, чтобы обеспечить собираемость проекта. И сначала с помощью IE развитие web'а было задержано на многие годы («наш сайт должен открываться в IE), а теперь посмотрите, много ли программ продолжают использовать mshtml для отображения HTML-контента. Нет, сейчас всем проще подключить webkit или что-то подобное. Я уж молчу, что в системе с нормальным API (на самом деле ABI) не устроили бы такой мощный DLL Hell, с которым пришлось бороться дополнительными ужасными и бессмысленными способами.
Наличие «широкого API» это огромный минус Windows. Это же API, а куча наслоений API из разных эпох. Стоит просто сравнить с тем, что предоставляется разработчику на MacOS или Android. Если вы на какое-то Windows API завяжетесь, то станете привязаны к Windows, а сейчас принято писать кроссплатформенные программы. Windows набивают разными библиотеками, а C++ runtime там вечно отстаёт от реальности и программы должны носить его с собой.
Не понравилось, что частота сканирования внешней клавиатуры совсем уж мала (внутренняя работает без нареканий),
Вообще-то клавиатуры никто не сканирует на уровне ОС. Тем более если вы говорите о внешней клавиатуре, подключенной по USB. Сканирует чип на самой клавиатуре, а в компьютер передаёт скан-коды. Видимо, на MacOS включен какой-то режим, ограничивающий частоту переключений, чтобы люди случайно не нажимали кнопки.
Это текст для плаката для демонстрации? Возможно, вы не в курсе, но wine такая же прослойка, как Win32 API в Windows. И ничего, ведь все Windows-программы его используют, и никто не кричит про прослойки. Почему вы не говорите про прослойки типа .NET Framework?
Да никто не обманывает. Действительно в WINE@Etersoft есть отличия. Хотя бы потому, что wine это свободный проект, а WINE@Etersoft — российский продукт на основе проекта wine. Коммиты в репозитории можете не смотреть — они старые. Но вы на публику вынесли своё несправедливое мнение, что вклад Etersoft в проект wine это три коммита. По некоторым причинам мы пока не афишируем наш вклад в wine, поэтому коммиты вы не увидите. Покупать программу не обязательно, частным лицам WINE@Etersoft предоставляется на безвозмездной основе. Если хотите поучаствовать в проекте, можем обсудить. Мало кому интересны исходники wine.
Видимо, чтобы не вводить в заблуждение, вас бы устроила фраза «Не покупайте WINE@Etersoft, всё и так работает в обычном wine». Но я сомневаюсь, что вы бы захотели работать в компании, которая так рекламирует свои продукты :)
Я пытался сказать простую вещь: у программ есть версии. И если вы сравниваете, нужно обязательно учитывать версию. В новой версии всегда есть изменения по сравнению с предыдущей. Собственно, об этом всегда и стараются написать.
Где я такие выводы нашёл? А вы почитайте, что вы пишете, и каким тоном. По поводу практики — мы используем самую лучшую практику из возможных, проверенную долгим опытом и позволяющую вести разработку свободного ПО. И не важно, что мы при этом специально делаем, потому что в практике всё делается специально для того, чтобы достичь результата.
По поводу формулировок это не ко мне. Но, собственно, они и не для вас, а для более простых людей, которые наверное прочитают там нужную им для выбора информацию. Вы тоже вот как-то из формулировки пресс-релиза какую-то философию хотите извлечь.
Мне нравится ваш настрой. Предлагаю объединить усилия по поводу тех поставщиков, которые действительно нарушают GPL. Дорабатываете/разрабатываете — это не придирка к словам? Ну как же ничего в замен, если вы нашли целых три коммита? Пусть несерьёзный вклад, и безусловно несоразмерный. А при каком количестве коммитов можно использовать труд большого числа людей?
Если вы программист, давайте я научу как коммиты искать: $ git log --pretty=oneline --abbrev-commit --author lav@etersoft.ru
98c67d8679b ncrypt: Add NCryptIsKeyHandle stub. 7cbaf1f56f6 advapi32/tests: Add test prototype for RegQueryValueEx HKEY_PERFORMANCE_DATA. 2884205db3a include: Add PERF_DATA_BLOCK struct definition. 7d258973544 po: Revise Russian translation. 6ceb5644083 ipconfig: Distinguish between IPv4 and IPv6 addresses in normal mode. 43ed0c177cc kernel32: Add Russian translation. b974852ce15 Update Russian translations. f8562ace96a wineconsole: Fix Russian translation. 934aa492b41 winex11: Add check for XmbTextPropertyToTextList result. aa5358fdae5 kernel32: gethostname returns string in CP_UNIXCP encoding. 98d0155371f include/ddk: Fix include path and include guard name. 977b7d398e1 wineboot: Do registry update with wineboot --update in any case.
Я постараюсь объяснить. Берём wine версии 5.0. Делаем доработки для лучшей работы с КОМПАСом и выпускаем WINE@Etersoft 5.0. Содержит изменения для лучшей работы? Содержит? Что этих изменений нет в апстриме, это вы сами додумали, потому что сравнивая с исходным wine, вы всегда будете видеть эти изменения, а если сравнивать с wine более новых версий, куда эти изменения уже приняты, отличий уже не будет. И вы что, предлагаете писать в рекламной фразе «WINE@Etersoft не содержит никаких изменений по сравнению с оригинальным wine»? :) Ваши выводы про то, что в апстрим отправлено или планируется, сделаны из неверных исходных данных, поэтому некорректны. К тому же, не каждое изменение могут принять, тем более сразу. С некоторыми мы по полгода работаем, чтобы их приняли. Но главное — когда наше изменение принимают, это снимает с нас нагрузку по его поддержке. У вас какой-то другой опыт работы с крупными апстримами? Поделитесь.
Мы отправляем в апстрим все изменения, какие возможно. Если бы вы смотрели внимательнее, то в интернете есть и статьи, как запустить КОМПАС-3D в обычном wine. Это как раз таки и возможно благодаря тому, что наши изменения отправлены в апстрим wine. Разрабатывать изменения, которые делают приложение функционирующим — это наша работа, а не отвратительная практика, как вы выразились. Вы хотели бы, чтобы мы их не разрабатывали? :) Возможно вы не совсем понимаете, чем свободный проект отличается от коммерческого продукта с поддержкой.
Мне кажется, или вы немного загибаете про сообщество? Думаю, что никто над «базовым продуктом» из тех, кто толкует здесь про LGPL, не работал. Если вы частное лицо, WINE@Etersoft предоставляется вам бесплатно. Какая прибыль? Если вы за организацию радеете, то какие-то патчи к wine из WINE@Etersoft вряд ли помогут. И поосторожнее с «не первый случай». Потому что мы-то как раз первый случай, и разрабатываем WINE@Etersoft уже 20 лет.
Из проекта удалена не только зависимость на линуксовую OpenAL, а удалена и реализация openal32.dll, поскольку в оригинальном Windows её нет, и она должна поставляться приложением:
«openal32: Remove dll. It's not part of Windows, so applications have to ship the native version anyway.»
Суть WordPad в том, что он использует системную библиотеку для работы с форматированным текстом (riched32.dl). Это такая же история, как с Internet Explorer — который использует системную mshtml.dll для отрисовки html. WordPad и IE это просто оболочки, а сами технологии из системы не выпилить, потому что есть множество программ, которых их используют.
wine это программа на C, которая может быть собрана под любую архитектуру. В частности, имеется поддержка aarch64 (ARMv8).
Несовместимость возникает, когда вы хотите запустить готовый EXE-файл. Тут wine должен быть собран под ту же архитектуру, что и EXE-файл. То есть без эмуляции запустить x86 бинарник на ARM не получится. А вот собрать и своё приложение и wine под ARM получится вполне.
Не очень понял, в чём я ошибаюсь.
WinAPI к ненативным GUI не имеет отношения, потому что они делаются вопреки (или же перпендикулярно) механизмам, предоставляемым WinAPI.
Ну вот я привожу Borland в пример, как явление, позволившее обеспечить масовую разработку софта для Windows, без ужасов WinAPI, а вы мне его же приводите в пример про кроссплатформенные приложения. Достоинства решений Borland лишь подчёркивают нищету WinAPI, а не являются следствием полезности WinAPI. И то, что там смогли сделать кроссплатформенность, к WinAPI никакого отношения не имеет.
В Винде нельзя быстро и удобно использовать нативный GUI. Это не быстро и не удобно. А .NET далеко не обёртка, слишком многое там сделано внутри, без перехода на unsafe code.
Вы вот вроде как утверждаете, что нет однородного API в Маке и Андроид, что там «меняется многое, как и в винде. Разные версии апи». Оно там меняется и есть разные версии апи. В WInAPI никаких версий API нет. Вы бы видели эти функции WinAPI, у которых порядок аргументов зависит от версии Windows.
Ещё раз, сравнивая с Андроид, где у вас есть возможность собираться с апи разных версий: в Windows ваше приложение обречено на линковку с ABI неизвестных версий, и это ключевая разница.
Про то, что «никогда не было проблем в Windows со сторонними библиотеками», не то, что бы это враньё, но не могу согласиться. Microsoft всегда вела себя так, как будто таких библиотек не существует. И да, вы верно заметили, устроила так, что эти библиотеки — головная боль разработчиков. А хотелось бы без головной боли. Например, vcpkg или что-то подобное.
Про MacOS и Android это был пример более стройного и однородного API. Понятно, что невозможно написать приложение без привязки к системе невозможно. Но только на WinAPI никто GUI-приложения не пишет. Это либо было MFC (которое умерло при первой возможности, когда стало возможным перейти на .NET), либо популярные разработки от Borland (библиотеки которых реализованы в стиле борьбы с трудностями WinAPI, то есть предоставляющие разработчикам то, что быть получено штатными средствами системы).
И как хорошо, что плюсовые библиотеки не всем нужны. Оказывается, уже можно не писать на C++. Достаточно .NET и требовать всего лишь обновления .NET Framework до 4.8.x, чтобы ваша программа запустилась.
В общем, стремление предоставить в API все сервисы (включая формирование электронных писем) это не для удобства программиста, это для того, чтобы привязать пользователей и разработчиков к своей системе. Привязать в плохом смысле. Десятилетия для Windows использование сторонних библиотек было проблемой — их откуда-то качали, куда-то клали, чтобы обеспечить собираемость проекта.
И сначала с помощью IE развитие web'а было задержано на многие годы («наш сайт должен открываться в IE), а теперь посмотрите, много ли программ продолжают использовать mshtml для отображения HTML-контента. Нет, сейчас всем проще подключить webkit или что-то подобное.
Я уж молчу, что в системе с нормальным API (на самом деле ABI) не устроили бы такой мощный DLL Hell, с которым пришлось бороться дополнительными ужасными и бессмысленными способами.
Наличие «широкого API» это огромный минус Windows. Это же API, а куча наслоений API из разных эпох. Стоит просто сравнить с тем, что предоставляется разработчику на MacOS или Android. Если вы на какое-то Windows API завяжетесь, то станете привязаны к Windows, а сейчас принято писать кроссплатформенные программы. Windows набивают разными библиотеками, а C++ runtime там вечно отстаёт от реальности и программы должны носить его с собой.
Вообще-то клавиатуры никто не сканирует на уровне ОС. Тем более если вы говорите о внешней клавиатуре, подключенной по USB. Сканирует чип на самой клавиатуре, а в компьютер передаёт скан-коды. Видимо, на MacOS включен какой-то режим, ограничивающий частоту переключений, чтобы люди случайно не нажимали кнопки.
Добавил в epm концептуальную поддержку установки портабельной версии far2l:
epm play far2l-portable
Это текст для плаката для демонстрации?
Возможно, вы не в курсе, но wine такая же прослойка, как Win32 API в Windows. И ничего, ведь все Windows-программы его используют, и никто не кричит про прослойки.
Почему вы не говорите про прослойки типа .NET Framework?
Лицензия (L)GPL вообще мне кажется не для организаций, а для программистов.
Ответ на этот на этот вопрос тянет на статью. На Хабре, конечно.
Да никто не обманывает. Действительно в WINE@Etersoft есть отличия. Хотя бы потому, что wine это свободный проект, а WINE@Etersoft — российский продукт на основе проекта wine.
Коммиты в репозитории можете не смотреть — они старые. Но вы на публику вынесли своё несправедливое мнение, что вклад Etersoft в проект wine это три коммита. По некоторым причинам мы пока не афишируем наш вклад в wine, поэтому коммиты вы не увидите.
Покупать программу не обязательно, частным лицам WINE@Etersoft предоставляется на безвозмездной основе.
Если хотите поучаствовать в проекте, можем обсудить. Мало кому интересны исходники wine.
Видимо, чтобы не вводить в заблуждение, вас бы устроила фраза «Не покупайте WINE@Etersoft, всё и так работает в обычном wine». Но я сомневаюсь, что вы бы захотели работать в компании, которая так рекламирует свои продукты :)
Я пытался сказать простую вещь: у программ есть версии. И если вы сравниваете, нужно обязательно учитывать версию.
В новой версии всегда есть изменения по сравнению с предыдущей. Собственно, об этом всегда и стараются написать.
Где я такие выводы нашёл? А вы почитайте, что вы пишете, и каким тоном.
По поводу практики — мы используем самую лучшую практику из возможных, проверенную долгим опытом и позволяющую вести разработку свободного ПО. И не важно, что мы при этом специально делаем, потому что в практике всё делается специально для того, чтобы достичь результата.
По поводу формулировок это не ко мне. Но, собственно, они и не для вас, а для более простых людей, которые наверное прочитают там нужную им для выбора информацию. Вы тоже вот как-то из формулировки пресс-релиза какую-то философию хотите извлечь.
Мне нравится ваш настрой. Предлагаю объединить усилия по поводу тех поставщиков, которые действительно нарушают GPL.
Дорабатываете/разрабатываете — это не придирка к словам?
Ну как же ничего в замен, если вы нашли целых три коммита? Пусть несерьёзный вклад, и безусловно несоразмерный. А при каком количестве коммитов можно использовать труд большого числа людей?
Если вы программист, давайте я научу как коммиты искать:
$ git log --pretty=oneline --abbrev-commit --author lav@etersoft.ru98c67d8679b ncrypt: Add NCryptIsKeyHandle stub.
7cbaf1f56f6 advapi32/tests: Add test prototype for RegQueryValueEx HKEY_PERFORMANCE_DATA.
2884205db3a include: Add PERF_DATA_BLOCK struct definition.
7d258973544 po: Revise Russian translation.
6ceb5644083 ipconfig: Distinguish between IPv4 and IPv6 addresses in normal mode.
43ed0c177cc kernel32: Add Russian translation.
b974852ce15 Update Russian translations.
f8562ace96a wineconsole: Fix Russian translation.
934aa492b41 winex11: Add check for XmbTextPropertyToTextList result.
aa5358fdae5 kernel32: gethostname returns string in CP_UNIXCP encoding.
98d0155371f include/ddk: Fix include path and include guard name.
977b7d398e1 wineboot: Do registry update with wineboot --update in any case.
Я постараюсь объяснить. Берём wine версии 5.0. Делаем доработки для лучшей работы с КОМПАСом и выпускаем WINE@Etersoft 5.0. Содержит изменения для лучшей работы? Содержит? Что этих изменений нет в апстриме, это вы сами додумали, потому что сравнивая с исходным wine, вы всегда будете видеть эти изменения, а если сравнивать с wine более новых версий, куда эти изменения уже приняты, отличий уже не будет. И вы что, предлагаете писать в рекламной фразе «WINE@Etersoft не содержит никаких изменений по сравнению с оригинальным wine»? :)
Ваши выводы про то, что в апстрим отправлено или планируется, сделаны из неверных исходных данных, поэтому некорректны.
К тому же, не каждое изменение могут принять, тем более сразу. С некоторыми мы по полгода работаем, чтобы их приняли.
Но главное — когда наше изменение принимают, это снимает с нас нагрузку по его поддержке.
У вас какой-то другой опыт работы с крупными апстримами? Поделитесь.
Мы отправляем в апстрим все изменения, какие возможно. Если бы вы смотрели внимательнее, то в интернете есть и статьи, как запустить КОМПАС-3D в обычном wine. Это как раз таки и возможно благодаря тому, что наши изменения отправлены в апстрим wine.
Разрабатывать изменения, которые делают приложение функционирующим — это наша работа, а не отвратительная практика, как вы выразились. Вы хотели бы, чтобы мы их не разрабатывали? :)
Возможно вы не совсем понимаете, чем свободный проект отличается от коммерческого продукта с поддержкой.
На всё есть свои причины. Вы чего именно хотите добиться? Если хотите, можете ваши коммиты показать.
Мне кажется, или вы немного загибаете про сообщество? Думаю, что никто над «базовым продуктом» из тех, кто толкует здесь про LGPL, не работал.
Если вы частное лицо, WINE@Etersoft предоставляется вам бесплатно. Какая прибыль?
Если вы за организацию радеете, то какие-то патчи к wine из WINE@Etersoft вряд ли помогут.
И поосторожнее с «не первый случай». Потому что мы-то как раз первый случай, и разрабатываем WINE@Etersoft уже 20 лет.
«the GPL requires you to make the modified source code available to the program's users»
Из проекта удалена не только зависимость на линуксовую OpenAL, а удалена и реализация openal32.dll, поскольку в оригинальном Windows её нет, и она должна поставляться приложением:
«openal32: Remove dll. It's not part of Windows, so applications have to ship the native version anyway.»
И в firefox и в chromium вижу одинаковое
Accept-Encoding: gzip, deflate, brВроде как brotli (которое тут под псевдонимом br) достаточно прогрессивное сжатие.