Ой, как хорошо тут! Все понимают о чём речь. А я вчера пробивался сквозь насмешки, доказывая, что GPS это в первую очередь точное время, а потом уже координаты, так как одного без другого быть не может. Увы, в ответ услышал только: ты чего, не знаешь, что GPS это куча спутников передающих твои координаты?!
Не знаю с каких пор, но diagrams.net пересылает теперь на draw.io с опенсорстным проектом. Функционала мне хватило с лихвой, принял на вооружение. Спасибо за статью!
Возможно я вас не понял, поправьте, если так. Но на скриншотах я не увидел ничего, что нельзя достаточно быстро сделать с помощью чистого win32 api. С Unicode win32 тоже отлично дружит, так что со спецсимволами тоже проблем нет.
По моему скромному опыту, фреймворки одну проблему решают, а две создают. Плакать хочется, когда на форумах mfc ищут решение проблемы, которая на win32 API даже бы и не появилась.
Про WIN32 API. Зачем для каждого элемента писать свой обработчик wm_paint, не понял? Если элемент нестандартный, можно использовать static стиль и рисовать в нём всё, что заблагорассудится, обрабатывая в едином стиле в одном wm_paint. К тому же, если нужен фон, то тут скорее WM_ERASEBKGND нужен. Вообще, мне опыт показал, что медлительность в разработке рождается от отсутствия сноровки. А когда сноровка есть, можно и на API и на любимом фреймворке написать с одинаковой эффективностью. Всё равно ни одного этапа разработки миновать не удастся.
Есть один защитный механизм организма, который не учитывают большинство худеющих. Если сжечь слишком много калорий, организм подарит упадок сил и на базовый обмен веществ потратит меньше калорий, чем обычно, компенсировав тем самым сожжённые при тренировках калории. Чтобы обойти этот механизм, нужно, как это не парадоксально, либо меньше тренироваться, либо больше кушать. Дефицит калорий для похудения, настоящего и эффективного, не должен быть выше 20% от того, что требуется вашему организму в сутки.
Обсуждение уходит в сторону. Либо я чего не понял. MenuetOS что, под Windows грузится? Или все же на голую платформу?
Он-то на голую, только нам для сравнения ассемблера с компилятором языка С операционная система никак не помешает, это и называется сравнением при прочих равных: система с её API, соглашение о вызовах, подключаемые библиотеки и архитектура конечного процессора - всё будет одинаковым. Разница будет только в том, кто сгенерирует ассемблерный код: программист или компилятор.
Я бы потягался под ARM
Что, так-таки без окружения? Назовите мне хоть одну причину настолько усложнять себе жизнь?
Скомпилили исходники на С, взяли листинг на ASM-е, чуть отрефакторили и обратно вставили в сорсы. Тут как раз проблем нет.
Речь вообще не о Windows, а о самостоятельных операционках.
Нет, речь именно о языках: я сказал, что ребята сильно заморочились, а вы в ответ, что это взято из исходников на C. Наберитесь мужества не съезжать с темы и отстаивать свою версию.
Ведь я утверждаю, что вы в корне не правы сказав, что для производства приложений MenuetOS достаточно взять gcc -S получишь готовый ассемблерный код.
И так, мы проверяем ваше утверждение делом или дальше слов вы не готовы? Я предлагаю честное сравнение: всё, кроме языков будет одинаковым.
Давайте не будем спорить, а просто напишем открытие простого окна в Windows (не диалогового, а с регистрацией оконного класса) и скомпилируем в exe, а затем сравним размер. Я напишу на ассемблере в соглашении о вызовах Windows64, а вы на С, также в режиме x64. Ещё, как опцию, можете исходник C скомпилировать в ассемблер и сравним их. Свою неправоту я признаю, если разница будет меньше 1 килобайта, а исходники приблизительно одинаковы по выполняемым действиям. Сразу уговор - никаких оптимизаций над уже готовым exe не проводим.
Конечно и неоднократно.Такое постоянно требуется в частности чтобы патчить отреверсенные дампы фирмваре устройств.
И получались легковесные исполняемые файлы? Чтобы не затягивать диалог, за вас отвечу - нет! Получались такие же, что и от компилятора C. Всё дело в том, что писать и мыслить на ассемблере имеет мало общего с тем, что делает компилятор C:
1. C - тащит за собой необходимый для исполнения минимум, даже если не подключать библиотеки;
2. C - не видит кода целиком, а ассемблирует каждую команду по отдельности без контекста. Вы не встретите в C эпизодов типа перехода в середину одной процедуры из другой по причине повторяемости кода типа:
Процедура1: a) Действие 1 б) Действие 2 в) Выход Процедура 2: a) Действие 3 б) Действие 4 в) Действие 5 г) переходим к Процедуре 1 к пункту б) чтобы произвести действие 2 и выйти.
3. С - не может проехать на одних только регистрах процессора, а многие программисты на асме зачастую именно так и поступают, не обращаясь лишний раз к памяти.
4. Ни один компилятор на планете не распараллелит расчёты для эффективного использования набора SIMD команд. Программисты на ассемблере делают это регулярно.
Реален ли размер MenuetOS? Вполне. 1 мегабайт настоящего ассемблера это годы работы и сотни тысяч строк кода. А если мыслить как вы, то и JAVA можно в ассемблер переложить вместе с JVM, только будет ли это программой написанной на ассемблере? - Вопрос риторический...
Твоюж налево! Я как-то раз SHA256 недели три по вечерам на асме писал, все мозги вывихнул. А тут даже с кодеками заморочились! Сколько же это времени заняло? И сколько человек в команде?..
Мне для этого достаточно 4 класса переписать, и точку входа. Если за это заплатят, портирую куда нужно.
А вот автору оригинала, по-видимому, за годы разработки, так и не пришла в голову идея о портировании. Ведь чего ему это стоит на Qt? Пересобрал и все. Да? Ведь да?
Ага. Скоро как у юристов будет: либо ты гений и решаешь проблемы компаний, либо сидишь в в офисе, инструктажами по ОТ занимаешься... И что-то мне подсказывает, на вершине "пищевой цепочки" программистов окажутся нифига не "node.js" - разработчики...
Отнюдь! Это штатный программист компании, и его лико светится на сайте среди руководства. Сама компания не занимается программированием, а продаёт товар, для которого и создана расчётная программа. То есть, смею предположить, что автор точно знал что нужно от продукта. И, кстати, ни для Linux в целом, ни для Android в частности, версии нет и не предвидится... Казалось бы - Qt: просто пересобери, да?..
Что именно не входит в API? Common Controls отменили? Или ListView? А может Статические элементы, которые вы обрабатываете и изменяете как захотите? Это во-первых. А во-вторых, никто даже в чистом API не прописывает интерфейс через окна. Существуют ресурсы, которые вы спокойно рисуете визуально мышкой. Обработка сообщений от контрола не сложнее и не проще, чем у Qt, просто она другая. И никакой фреймворк вас от этого не освободит. Меняется лишь способ, а временные затраты практически те же. А вот вашему пользователю будет намного проще и скачать и установить это, хотя бы по соображениям затраченного времени. Помните как в сайтах? 4 секунды грузится- половина посетителей отваливается. А почему с загрузкой установщика по-другому? Особенно если программа скачивается только для того, чтобы посчитать и принять решение о покупке, да и то есть сомнения - а нужно ли это мне сейчас? Ещё и грузится долго... Думаете просто так все гуглы и микрософты компактные установщики дают, которые в свою очередь выкачивают нужное? Это в том числе и для разделения времени ожидания.
Лицензия. Qt для коммерческого ПО с закрытым исходным кодом требует другой лицензии, нежели при его использовании в opensource.
Всё вышеперечисленное автором.
Любое усложнение запуска программы отпугивает большой процент пользователей (тут вопрос -тащить за собой зависимости или распространять единственный (подписанный) exe-файл. Я до сих пор уверен, что у одного разорившегося маркетплейса проблемы начались именно после того, как они принудительно перевели всех покупателей на двухфакторную аутентификацию, дико усложнив жизнь огромному проценту покупателей, которые в качестве решения проголосовали ногами.
То есть, тут вопрос не экономии строчек кода (напротив, строчек, как правило больше при нативном подходе), а забота о пользователе и энергосистеме государства. Ну и, конечно же, о собственном кармане, как бы не парадоксально это звучало.
Тут, как говорится - любой каприз за ваши деньги:-)
А если серьёзно, при продуманном проектировании, для переноса на android, потребуется дописать только интерфейс, который и без того пришлось бы перелопачивать при проектировании кроссплатформенного решения. А начинку вызывать как API через JNI. Работы на самом деле не на много больше.
Ой, как хорошо тут! Все понимают о чём речь. А я вчера пробивался сквозь насмешки, доказывая, что GPS это в первую очередь точное время, а потом уже координаты, так как одного без другого быть не может. Увы, в ответ услышал только: ты чего, не знаешь, что GPS это куча спутников передающих твои координаты?!
У меня на такие случаи простенький CMakeLists.txt всегда наготове. В связке VSCode+cmake плагины это также превращается в однокнопочное решение.
Не знаю с каких пор, но diagrams.net пересылает теперь на draw.io с опенсорстным проектом. Функционала мне хватило с лихвой, принял на вооружение. Спасибо за статью!
Возможно я вас не понял, поправьте, если так. Но на скриншотах я не увидел ничего, что нельзя достаточно быстро сделать с помощью чистого win32 api. С Unicode win32 тоже отлично дружит, так что со спецсимволами тоже проблем нет.
По моему скромному опыту, фреймворки одну проблему решают, а две создают. Плакать хочется, когда на форумах mfc ищут решение проблемы, которая на win32 API даже бы и не появилась.
Про WIN32 API. Зачем для каждого элемента писать свой обработчик wm_paint, не понял? Если элемент нестандартный, можно использовать static стиль и рисовать в нём всё, что заблагорассудится, обрабатывая в едином стиле в одном wm_paint. К тому же, если нужен фон, то тут скорее WM_ERASEBKGND нужен. Вообще, мне опыт показал, что медлительность в разработке рождается от отсутствия сноровки. А когда сноровка есть, можно и на API и на любимом фреймворке написать с одинаковой эффективностью. Всё равно ни одного этапа разработки миновать не удастся.
Есть один защитный механизм организма, который не учитывают большинство худеющих. Если сжечь слишком много калорий, организм подарит упадок сил и на базовый обмен веществ потратит меньше калорий, чем обычно, компенсировав тем самым сожжённые при тренировках калории. Чтобы обойти этот механизм, нужно, как это не парадоксально, либо меньше тренироваться, либо больше кушать. Дефицит калорий для похудения, настоящего и эффективного, не должен быть выше 20% от того, что требуется вашему организму в сутки.
Он-то на голую, только нам для сравнения ассемблера с компилятором языка С операционная система никак не помешает, это и называется сравнением при прочих равных: система с её API, соглашение о вызовах, подключаемые библиотеки и архитектура конечного процессора - всё будет одинаковым. Разница будет только в том, кто сгенерирует ассемблерный код: программист или компилятор.
Что, так-таки без окружения? Назовите мне хоть одну причину настолько усложнять себе жизнь?
Нет, речь именно о языках: я сказал, что ребята сильно заморочились, а вы в ответ, что это взято из исходников на C. Наберитесь мужества не съезжать с темы и отстаивать свою версию.
Ведь я утверждаю, что вы в корне не правы сказав, что для производства приложений MenuetOS достаточно взять gcc -S получишь готовый ассемблерный код.
И так, мы проверяем ваше утверждение делом или дальше слов вы не готовы? Я предлагаю честное сравнение: всё, кроме языков будет одинаковым.
Давайте не будем спорить, а просто напишем открытие простого окна в Windows (не диалогового, а с регистрацией оконного класса) и скомпилируем в exe, а затем сравним размер. Я напишу на ассемблере в соглашении о вызовах Windows64, а вы на С, также в режиме x64. Ещё, как опцию, можете исходник C скомпилировать в ассемблер и сравним их. Свою неправоту я признаю, если разница будет меньше 1 килобайта, а исходники приблизительно одинаковы по выполняемым действиям. Сразу уговор - никаких оптимизаций над уже готовым exe не проводим.
И получались легковесные исполняемые файлы? Чтобы не затягивать диалог, за вас отвечу - нет! Получались такие же, что и от компилятора C. Всё дело в том, что писать и мыслить на ассемблере имеет мало общего с тем, что делает компилятор C:
1. C - тащит за собой необходимый для исполнения минимум, даже если не подключать библиотеки;
2. C - не видит кода целиком, а ассемблирует каждую команду по отдельности без контекста. Вы не встретите в C эпизодов типа перехода в середину одной процедуры из другой по причине повторяемости кода типа:
Процедура1:
a) Действие 1
б) Действие 2
в) Выход
Процедура 2:
a) Действие 3
б) Действие 4
в) Действие 5
г) переходим к Процедуре 1 к пункту б) чтобы произвести действие 2 и выйти.
3. С - не может проехать на одних только регистрах процессора, а многие программисты на асме зачастую именно так и поступают, не обращаясь лишний раз к памяти.
4. Ни один компилятор на планете не распараллелит расчёты для эффективного использования набора SIMD команд. Программисты на ассемблере делают это регулярно.
Реален ли размер MenuetOS? Вполне. 1 мегабайт настоящего ассемблера это годы работы и сотни тысяч строк кода.
А если мыслить как вы, то и JAVA можно в ассемблер переложить вместе с JVM, только будет ли это программой написанной на ассемблере? - Вопрос риторический...
Можно уточнить, вы когда-нибудь проделывали описываемую вами процедуру, с которой "Тут как раз проблем нет"?
Твоюж налево! Я как-то раз SHA256 недели три по вечерам на асме писал, все мозги вывихнул. А тут даже с кодеками заморочились! Сколько же это времени заняло? И сколько человек в команде?..
Так и большинство не знает, что можно как-то иначе (или не умеет). Об этом и вся статья. Если в руках молоток, то всё вокруг - гвозди.
Мне для этого достаточно 4 класса переписать, и точку входа. Если за это заплатят, портирую куда нужно.
А вот автору оригинала, по-видимому, за годы разработки, так и не пришла в голову идея о портировании. Ведь чего ему это стоит на Qt? Пересобрал и все. Да? Ведь да?
Ага. Скоро как у юристов будет: либо ты гений и решаешь проблемы компаний, либо сидишь в в офисе, инструктажами по ОТ занимаешься... И что-то мне подсказывает, на вершине "пищевой цепочки" программистов окажутся нифига не "node.js" - разработчики...
https://habr.com/ru/articles/789550/comments/#comment_26438962 ниже ответил. Версий под перечисленные платформы у оригинальной программы также нет и не предвидится.
Отнюдь! Это штатный программист компании, и его лико светится на сайте среди руководства. Сама компания не занимается программированием, а продаёт товар, для которого и создана расчётная программа. То есть, смею предположить, что автор точно знал что нужно от продукта. И, кстати, ни для Linux в целом, ни для Android в частности, версии нет и не предвидится... Казалось бы - Qt: просто пересобери, да?..
Что именно не входит в API? Common Controls отменили? Или ListView? А может Статические элементы, которые вы обрабатываете и изменяете как захотите? Это во-первых. А во-вторых, никто даже в чистом API не прописывает интерфейс через окна. Существуют ресурсы, которые вы спокойно рисуете визуально мышкой. Обработка сообщений от контрола не сложнее и не проще, чем у Qt, просто она другая. И никакой фреймворк вас от этого не освободит. Меняется лишь способ, а временные затраты практически те же. А вот вашему пользователю будет намного проще и скачать и установить это, хотя бы по соображениям затраченного времени. Помните как в сайтах? 4 секунды грузится- половина посетителей отваливается. А почему с загрузкой установщика по-другому? Особенно если программа скачивается только для того, чтобы посчитать и принять решение о покупке, да и то есть сомнения - а нужно ли это мне сейчас? Ещё и грузится долго... Думаете просто так все гуглы и микрософты компактные установщики дают, которые в свою очередь выкачивают нужное? Это в том числе и для разделения времени ожидания.
Лицензия. Qt для коммерческого ПО с закрытым исходным кодом требует другой лицензии, нежели при его использовании в opensource.
Всё вышеперечисленное автором.
Любое усложнение запуска программы отпугивает большой процент пользователей (тут вопрос -тащить за собой зависимости или распространять единственный (подписанный) exe-файл. Я до сих пор уверен, что у одного разорившегося маркетплейса проблемы начались именно после того, как они принудительно перевели всех покупателей на двухфакторную аутентификацию, дико усложнив жизнь огромному проценту покупателей, которые в качестве решения проголосовали ногами.
То есть, тут вопрос не экономии строчек кода (напротив, строчек, как правило больше при нативном подходе), а забота о пользователе и энергосистеме государства. Ну и, конечно же, о собственном кармане, как бы не парадоксально это звучало.
Тут, как говорится - любой каприз за ваши деньги:-)
А если серьёзно, при продуманном проектировании, для переноса на android, потребуется дописать только интерфейс, который и без того пришлось бы перелопачивать при проектировании кроссплатформенного решения. А начинку вызывать как API через JNI. Работы на самом деле не на много больше.