Смысл хардкодить из json во время компиляции? Проще тогда сразу средствами языка всё описать и в include подключить. А рефлексия во время выполнения это средство расширения функционала без переписывания кода.
Ток никуда не идёт. Напряжение возрастает из за плохой проводимости между концами катушки. Чем больше проводимость тем меньше напряжение и больше ток, и наоборот.
Запускались до выхода 2000 включительно и частично на XP.
Позже этот слой двоичной совместимости убрали из за множества багов и дыр.
Я как то писал прогу для DOS работавшую с железом напрямую, так было проще отлаживаться под Win2k т.к. она не дохла как чистый DOS из за ошибок обращения к памяти. Убил процесс или система его сама убила и исправляй ошибки.
Заметьте, я говорил о совместимости по исходным текстам.
И сейчас можно собрать программу из исходников для Win 3.1 без изменений, и запустить на Win11. Проделывал такой трюк не так давно.
Да, есть проблемы с кодировкой, специально их не исправлял. Код из 1992 года.
Они вообще регистры только на картинках видели, а там буфер ассоциативной трансляции, регистры виртуализации и прочие страшные штуки. Я молчу про инициализацию процессора и памяти, про загрузку ядра и переключение контекста, там всё на асме, как он туда на расте намылились?
Всё там уже в нектором роде есть:
pub extern "C" fn _start() -> ! {
use x86_64::registers::control::Cr3;
use x86_64::structures::paging::PageTable;
let level_4_table_ptr = 0xffff_ffff_ffff_f000 as *const PageTable;
let (level_4_page_table, _) = Cr3::read();
Есть.
Нет гарантии что статическая рефлексия защищает от ошибок.
Это вы тут реально достали своим ущербным мышлением в парадигме статической рефлексии.
На Java гнать волну не стоит.
Смысл хардкодить из json во время компиляции? Проще тогда сразу средствами языка всё описать и в include подключить.
А рефлексия во время выполнения это средство расширения функционала без переписывания кода.
Ага. И поэтому в цепь реле управляющего транзистора ставят диод.
Интересно для чего.
Поиграйтесь с катушкой зажигания и батарейкой, эта схема вам быстро прояснит ситуацию с вашим неправильным утверждением.
Ток никуда не идёт. Напряжение возрастает из за плохой проводимости между концами катушки. Чем больше проводимость тем меньше напряжение и больше ток, и наоборот.
Запускались до выхода 2000 включительно и частично на XP.
Позже этот слой двоичной совместимости убрали из за множества багов и дыр.
Я как то писал прогу для DOS работавшую с железом напрямую, так было проще отлаживаться под Win2k т.к. она не дохла как чистый DOS из за ошибок обращения к памяти. Убил процесс или система его сама убила и исправляй ошибки.
Заметьте, я говорил о совместимости по исходным текстам.
И сейчас можно собрать программу из исходников для Win 3.1 без изменений, и запустить на Win11. Проделывал такой трюк не так давно.
Да, есть проблемы с кодировкой, специально их не исправлял. Код из 1992 года.
Обратная совместимость между DOS-based и NT-based системами Windows обеспечивается на уровне исходного кода.
По двоичному коду они несовместимы.
Что же касается фактической обратной двоичной совместимости -- до Windows остальным как до Луны.
В RSX формат имени файла 6.3.
8.3 это MSDOS
В основном обратная совместимость.
Кому надо регистрозависимость ФС просто её включит молча.
Может там суперконденсаторы для старта.
Это сейчас было про DOS или про Excel?
Чего уж проще -- никогда никому не говорить никаких кодов по телефону.
А если бы ЦБ купил биткоин то сколько он бы НЕ профукал?
Никак не упомянут Пролог. Жив ли ещё.
Всё там уже в нектором роде есть:
(с) https://habr.com/ru/articles/436606/
В своё время пользовался очень компактным рендером, с весьма качественной реализацией.
https://agg.sourceforge.net/antigrain.com/index.html
Очень хорошо работает в условиях недостатка памяти.
В частности на нём была написана iGo для КПК ещё в каменном веке.
Второе, насчёт GUI для старых систем, рекламирую второй раз на хабре - Zinc!
Пользуюсь известным принципом -- простое объяснение является самым верным.
Ваша версия и ещё множество их тоже имеют право на обсуждение.