А что понимать, современный софт основан на свободном коде. Никакого VS Code не появилось бы без Atom, а для Atom сделали electron, а до этого придумали JS-движок V8 взять из chromium и сделать nodejs. Это не «декомпозировать», это пояснение, каким образом становится возможным делать новые хорошие решения. Можно не декомпозировать Android, но его не появилось бы без Linux. И ничего Microsoft нам не дал по сравнению с тем, сколько он отнял, исказив всю отрасль разработки ПО, монополизировав платформу. Ещё десятилетия индустрия будет выбираться из Windows-капкана для прикладных программ.
А исходники electron (chromium + nodejs), который используется в vscode, Microsoft дал или взял? Для разжатия картинок в Windows использовался свободный libjpeg (почитайте ThirdPartyNotices.txt на предмет This this software is based in part on the work of the Independent JPEG Group. Мне кажется, это даже в окошке с лицензией выводилось). 20 лет назад был в отличном состоянии компилятор gcc, а не тот ужас, который предлагает MS. А исходники PowerShell вообще никому не сдались.
Но это же неправда. Вы зачем-то называете использование библиотек (в том числе системных) трансляцией вызовов API. Посмотрите, как в Windows вызовы WinAPI являются обёртками вокруг NTAPI. Разные слои абстраций это неотъемлемое следствие сложности системы, а также пройденного ею исторического пути. Названный вами набор костылей (на самом деле Wine это альтернативная реализация библиотек Windows) каким-то образом при добавлении в ReacOS делает её системой, совместимой с Windows. Чем вы хотите упрекнуть, что для раскодирования JPEG используется libjpeg, а код не написан с нуля? Что для чтения файлов wine обращается к ядру Linux? О ужас, они не сами файлы открывают, читая сектора с диска. Зачем вы придерживаетесь заблуждений, это ваше дело, но распространение заблуждений это дело уже общественное.
Суть 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. Разрабатывать изменения, которые делают приложение функционирующим — это наша работа, а не отвратительная практика, как вы выразились. Вы хотели бы, чтобы мы их не разрабатывали? :) Возможно вы не совсем понимаете, чем свободный проект отличается от коммерческого продукта с поддержкой.
А что понимать, современный софт основан на свободном коде. Никакого VS Code не появилось бы без Atom, а для Atom сделали electron, а до этого придумали JS-движок V8 взять из chromium и сделать nodejs. Это не «декомпозировать», это пояснение, каким образом становится возможным делать новые хорошие решения. Можно не декомпозировать Android, но его не появилось бы без Linux.
И ничего Microsoft нам не дал по сравнению с тем, сколько он отнял, исказив всю отрасль разработки ПО, монополизировав платформу. Ещё десятилетия индустрия будет выбираться из Windows-капкана для прикладных программ.
А исходники electron (chromium + nodejs), который используется в vscode, Microsoft дал или взял? Для разжатия картинок в Windows использовался свободный libjpeg (почитайте ThirdPartyNotices.txt на предмет This this software is based in part on the work of the Independent JPEG Group. Мне кажется, это даже в окошке с лицензией выводилось). 20 лет назад был в отличном состоянии компилятор gcc, а не тот ужас, который предлагает MS.
А исходники PowerShell вообще никому не сдались.
Но это же неправда. Вы зачем-то называете использование библиотек (в том числе системных) трансляцией вызовов API. Посмотрите, как в Windows вызовы WinAPI являются обёртками вокруг NTAPI. Разные слои абстраций это неотъемлемое следствие сложности системы, а также пройденного ею исторического пути. Названный вами набор костылей (на самом деле Wine это альтернативная реализация библиотек Windows) каким-то образом при добавлении в ReacOS делает её системой, совместимой с Windows.
Чем вы хотите упрекнуть, что для раскодирования JPEG используется libjpeg, а код не написан с нуля? Что для чтения файлов wine обращается к ядру Linux? О ужас, они не сами файлы открывают, читая сектора с диска.
Зачем вы придерживаетесь заблуждений, это ваше дело, но распространение заблуждений это дело уже общественное.
Это пример того, как сначала латинизируют письменность, а потом приводят к гражданской войне.
Суть 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.
Разрабатывать изменения, которые делают приложение функционирующим — это наша работа, а не отвратительная практика, как вы выразились. Вы хотели бы, чтобы мы их не разрабатывали? :)
Возможно вы не совсем понимаете, чем свободный проект отличается от коммерческого продукта с поддержкой.
На всё есть свои причины. Вы чего именно хотите добиться? Если хотите, можете ваши коммиты показать.