Comments 56
Ну как-бы это давно пройдённый этап: ещё Qnx в 1990-х сделала инсталляцию ОС на дискету: несколько утилит и даже интернет-браузер - можно было лазать по интернет.
А вот кнопочка Donate - это да, собираем денежки. Однако, лучше было бы поставить тэг "реклама".
Сарказм: название операционки тоже слегка "доставляет".
Этой операционке тоже много лет. Я про нее читал еще лет 20 назад.
название операционки тоже слегка "доставляет".
Бивис, он сказал менуэт, гыы, гы, гы, гыыыыы.
И ему теперь дадут. И это будет клёво.
Да, точно, баклан! :)
Прямо детский сад какой-то, "штаны на лямках".
Поясняю: в слове "менуэт" ничего особенного нет. "Сарказм" слов появляется после добавления суффикса ОС.
Теперь по-русски: Если кто-то создал программу "Глобальный Обсчёт Внутреннего Напряжения" и сократил до "Говн" - ну хорошо, пусть так и называется. Однако, если на основе этого "Обсчёта" создадут операционную систему и обзовут "ГовнОС", то это уже явная заявка на сарказм/троллинг.
С обсуждаемой ОС та же ситуация. Причём создатели были очень в курсе этого сочетания (есть такое подозрение). Поэтому сарказм-сарказм.
Первый выпуск был в 2000 году. Та легендарная QNX 4.25 (точнее, её демо-версия Incredible 1.44M Demo) всего на год её старше.
Умещается _на что_?
Для запуска на 64-битной системе, где даже L2 кэш больше, чем 1.44 МБ?
А дискету где взять?
С помощью WinImage сделать. Всё вам, молодежи, объяснять надо )
30 рублей и она у вас.
А я думал, что Menuet умер и от него ответвился kolibrios, оказывается обе ещё живы
В браузере есть поддержка хотя бы mjs скриптов? CSS?
Судя по скрину с сайтом hothardware.com как минимум CSS поддерживается.
Интересный проект. Сайт в браузере с моноширинным шрифтом выглядит потрясающе.
Вообще, играя в такие системы, было бы интересно заменить ассемблер каким-то своим языком программирования, но так чтобы по возможности не получить ни единого лишнего байта при компиляции. Это весьма любопытно потому, что потенциально позволило бы получить в высокоуровневом языке абстракции, вероятно не имеющие аналогов даже в Си, и соответственно обогатить языки программирования как таковые какими-то новыми подходами.
zig и отчасти rust
а также, внезапно, C# - Собираем автономную игру на C# в 2 килобайтах / Хабр (habr.com)
Ассемблер это не язык программирования в полном смысле этого слова, это последовательность инструкций для процессора, машинный код в приятном для прочтения|написания виде. загрузку числа в регистр как не назови, она всё равно останется этой же инструкцией.
Ассемблер переводит инструкции машинного кода в удобочитаемый вид. )))
Это описание несколько подустарело с появлением макроассемблера. А еще был ассемблер с объектно ориентированными заморочками. Если не путаю, оно в последних версиях турбо ассемблера было.
Конечно, в основном там код формировался командами процессора в текстовом представлении, но были и абстракции более высоких уроыней: как минимум макроопределения и директивы программе сборки (модель памяти, распределение данных по сегментам, текстовые метки перезодов, выравнивание данеыз и т.п.), а в особо запущенном случае поддержка объектов (тут деталей уже не помню).
В virtualbox она не запускается, арет что проц у тебя не 64 бит и приехали
А так мое почтение разработчику!
Твоюж налево! Я как-то раз SHA256 недели три по вечерам на асме писал, все мозги вывихнул. А тут даже с кодеками заморочились! Сколько же это времени заняло? И сколько человек в команде?..
Скомпилили исходники на С, взяли листинг на ASM-е, чуть отрефакторили и обратно вставили в сорсы. Тут как раз проблем нет.
Из образа дискеты видно что игры, сервера, редакторы, VNC и проч. они подкачивают со стороннего диска. Т.е. на дискете по сути просто загрузчик, а не вся ось. Потом ещё что-то надо воткнуть чтобы загрузилось остальное, и написанное совсем не на ассемблере.
Можно уточнить, вы когда-нибудь проделывали описываемую вами процедуру, с которой "Тут как раз проблем нет"?
Конечно и неоднократно.
Такое постоянно требуется в частности чтобы патчить отреверсенные дампы фирмваре устройств.
Ну я бы посмотрел на человека, способного рефакторить дизассемблированный код после оптимизации. А при наличии исходников не вижу смысла соревноваться с компилятором.
соревноваться с компилятором и не нужно. Компилятор ни когда не увидит то, что может увидеть человек. Потому микрооптимизации зачастую не нужны. А вот оптимизации по коду будут полезны, но компилятор с подобными оптимизациями не справится, по простой причине, что его этому не учили.
Я про те моменты когда надо сопоставить код в разных местах и основываясь на общем коде произвести оптимизацию в одной части, чтоб работа в другой части выполнялась быстрее (что-то вроде рефакторинга кода).
Ну я бы посмотрел на человека, способного рефакторить дизассемблированный код после оптимизации.
Здравствуйте.
Ну, если честно, не рефакторить, а читать, анализировать и вставлять какие-то затычки. Это не запредельно сложно (особенно в разрезе "фирмваре дампов" - тут ситуация с оптимизирующими компиляторами СИЛЬНО хуже, чем в "большом" мире).
Конечно и неоднократно.Такое постоянно требуется в частности чтобы патчить отреверсенные дампы фирмваре устройств.
И получались легковесные исполняемые файлы? Чтобы не затягивать диалог, за вас отвечу - нет! Получались такие же, что и от компилятора 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, только будет ли это программой написанной на ассемблере? - Вопрос риторический...
Вы б матчасть подтянули бы, а?..
C - тащит за собой необходимый для исполнения минимум
Не тащит, если специально попросить. Ни разу не пробовал подобное для больших машин, но регулярно делаю прошивки под МК, которые содержат ТОЛЬКО то, что лежит в каталоге sources проекта.
C - не видит кода целиком, а ассемблирует каждую команду по отдельности без контекста.
Когда-то давно Renesas сделал аж специальную инструкцию в своих процессорах, чтобы сделать общий пролог-эпилог в функциях. И компиляторы были, которые делали эти общие "саб-функции", которые стек сохраняли-восстанавливали. Только практика показывает, что памяти экономиться там всего ничего, а скорость только уменьшается.
С - не может проехать на одних только регистрах процессора, а многие программисты на асме зачастую именно так и поступают, не обращаясь лишний раз к памяти.
Зачем?! Если для скорости - в 99% случае компилятор сам не будет генерировать лишние обращения к памяти. Единственный смысл, какой могу придумать - стартап код в какой-то странной железке, которой надо инициализировать память. И вот до этого момента надо иметь гарантию, что туда никто не полезет.
Ни один компилятор на планете не распараллелит расчёты для эффективного использования набора SIMD команд.
М-м-м, какое прекрасное обобщение. Главное - его ни доказать, ни опровергнуть нельзя. Но что-то мне кажется, это вообще не про обсуждаемую операционку (или оно там прямо в ядре видео кодирует?).
Давайте не будем спорить, а просто напишем открытие простого окна в Windows (не диалогового, а с регистрацией оконного класса) и скомпилируем в exe, а затем сравним размер. Я напишу на ассемблере в соглашении о вызовах Windows64, а вы на С, также в режиме x64. Ещё, как опцию, можете исходник C скомпилировать в ассемблер и сравним их. Свою неправоту я признаю, если разница будет меньше 1 килобайта, а исходники приблизительно одинаковы по выполняемым действиям. Сразу уговор - никаких оптимизаций над уже готовым exe не проводим.
Речь вообще не о Windows, а о самостоятельных операционках.
Если что и сравнивать с MenuetOS так это что-нибудь вроде Azure RTOS, Zephyr, Free RTOS и подобными.
А в качестве GUI взять что-нибудь типа GUIX, emGUI.
Так вот эти операционки с оконным GUI, TCP стеком, USB стеком, файловой системой написанные на C будут гораздо меньше MenuetOS.
И попробуйте там переписать их на ассемблере чтобы сэкономить хотя бы килобайт.
В оправдание такого огромного минимального размера MenuetOS могу только предположить наличие в ней несжатых ресурсов в виде пиктограмм, текстовых панелей, шрифтов и прочих графических артефактов которые им нужны чтобы старательно изображать десктоп.
Скомпилили исходники на С, взяли листинг на ASM-е, чуть отрефакторили и обратно вставили в сорсы. Тут как раз проблем нет.
Речь вообще не о Windows, а о самостоятельных операционках.
Нет, речь именно о языках: я сказал, что ребята сильно заморочились, а вы в ответ, что это взято из исходников на C. Наберитесь мужества не съезжать с темы и отстаивать свою версию.
Ведь я утверждаю, что вы в корне не правы сказав, что для производства приложений MenuetOS достаточно взять gcc -S получишь готовый ассемблерный код.
И так, мы проверяем ваше утверждение делом или дальше слов вы не готовы? Я предлагаю честное сравнение: всё, кроме языков будет одинаковым.
Обсуждение уходит в сторону. Либо я чего не понял. MenuetOS что, под Windows грузится? Или все же на голую платформу?
Если на голую, то всякие отсылки к компиляторам под Windows считаю неуместными.
Я бы потягался под ARM
Обсуждение уходит в сторону. Либо я чего не понял. MenuetOS что, под Windows грузится? Или все же на голую платформу?
Он-то на голую, только нам для сравнения ассемблера с компилятором языка С операционная система никак не помешает, это и называется сравнением при прочих равных: система с её API, соглашение о вызовах, подключаемые библиотеки и архитектура конечного процессора - всё будет одинаковым. Разница будет только в том, кто сгенерирует ассемблерный код: программист или компилятор.
Я бы потягался под ARM
Что, так-таки без окружения? Назовите мне хоть одну причину настолько усложнять себе жизнь?
Всё, я сдаюсь, вы победили.
Я довольно плохо знаю винапи, чтобы подобным заниматься. Экономить байты прошивки, чтобы купить младшие в линейке контроллеры с минимумом памяти - было. Экономить такты, чтобы в имеющееся изделие добавить приёмник хитрого протокола со скоростью 500кбит/с на чистом "ногодрыге" и таймерах, и ещё время остававить на выполнение основных задач - было. На плюсах, но с внимательным разглядыванием получившегося бинарника через objdump.
А этой фигнёй регистрацией оконного класса только по большой любви можно страдать.
Я так понимаю, что если ось маленькая и на ассемблере, то она очень быстрая. Интересно, имеет ли это смысл для математики? Какой-нибудь компилятор Си есть для неё?
Не совсем понятно про какую модифированную версию MIT тут говорится. Menuet64 распространяется под проприетарной лицензией https://menuetos.net/m64l.txt, тех пор, как KolibriOS объявлена самим Вилли "вражеским форком".
Остаётся найти дисковод
Если она под x86_64, то зачем это крохоборство с ресурсами?
Если она суперлёгкая и супероптимизированная, то зачем она 64-битная и под x86_64, а не скажем 32-битная под Cortex-M? Ну или хотя бы Arm64.
Поставил вчера поглядел на это чудо (была у меня дискета с QNX лет 15-20 что-ли назад)... и удалил. ПС: ставит надо на Other 64 bit. кстати.
Меня в видео поражает без преувеличения мгновенный отклик системы на нажатие по иконке на рабочем столе. Буквально клик и перед тобой сразу же готовое окно с содержимым, а не тяжело пыхтя вываливающаяся рамка окна с последующей лениво подгружающейся строкой инструментов и, наконец, грузно и с одышкой приходящее содержимое окна, силящееся всё это время отобразить меньше десятка иконок моих дисков и папок, по сути нескольких картинок и пары текстов. И всё это на современной машине, разумеется.
Релиз MenuetOS 1.50, которая написана на ассемблере и умещается на дискету