Исправление X512, (текущая версия) :
Над реактосью же довлеет проклятие винды.
Никакого проклятия. Там царит карго культ и токсичность (постоянное упоминание как они никому ничего не обязаны, ответы в грубой форме, избыточная бюрократия). Под карго культом я понимаю доскональное воспроизводство Windows там где в этом нет технической необходимости. Например вслед за Windows повторяют ошибку с графической подсистемой в ядре (win32k.sys). Это имело смысл только для совсем слабого железа, сейчас графика прекрасно работает в отдельном процессе пользователя. В том же Wine никаких модулей ядра не требуется. В Windows NT 3.x графика тоже была в процессе пользователя.
Haiku не воспроизводит все внутренние API и протоколы BeOS, например GUI сервер app_server в BeOS и Haiku несовместимы между собой и используют разные протоколы, но кроме системных библиотек этот протокол никто не использует так что несовместимость проблем не вызывает. В ReactOS же зачем-то пытаются воспроизвести все внутренние API и протоколы которые нигде кроме внутренних компонентов Windows не используются и на совместимость приложений с драйверами не влияют.
Также в ReactOS серьёзные проблемы с процессом разработки и тестированием. Несмотря на большое количество критических багов в ядре и ядерной графической подсистеме, всё это запускают вместе что крайне затрудняет поиск причин багов, падение ядра может быть вызвано порчей памяти в win32k.sys и наоборот. На раннем этапе разработки когда ядро ещё не стабильно, разумно его тестировать отдельно от графики и других компонентов чтобы снизить влияние багов в этих компонентах и локализовать баги ядра.
Тестовые сборки зачем-то настроены как релизные. Кому нужен BSOD в альфа версии нестабильной системы, из которого ничего понять невозможно? Очередное проявление карго культа. Надо сразу при kernel panic показывать на экране отладчик ядра с автоматическим выводом стека как это делает Haiku. Это позволяет сделать фото экрана и отправить разработчикам и не требует от пользователя навыков отладки ядра.
Иногда у меня возникает впечатление что если начать новый проект клона Windows с нуля другой командой разработчиков, то он будет готов раньше ReactOS. ReactOS оттягивает ресурсы и не даёт сделать нормальный клон. В этом смысле ReactOS даже выгоден Microsoft.
Исправление X512, :
Над реактосью же довлеет проклятие винды.
Никакого проклятия. Там царит карго культ и токсичность (постоянное упоминание как они никому ничего не обязаны, ответы в грубой форме, избыточная бюрократия). Под карго культом я понимаю доскональное воспроизводство Windows там где в этом нет технической необходимости. Например вслед за Windows повторяют ошибку с графической подсистемой в ядре (win32k.sys). Это имело смысл только для совсем слабого железа, сейчас графика прекрасно работает в отдельном процессе пользователя. В том же Wine никаких модулей ядра не требуется. В Windows NT 3.x графика тоже была в процессе пользователя.
Haiku не воспроизводит все внутренние API и протоколы BeOS, например GUI сервер app_server в BeOS и Haiku несовместимы между собой и используют разные протоколы, но кроме системных библиотек этот протокол никто не использует так что несовместимость проблем не вызывает. В ReactOS же зачем-то пытаются воспроизвести все внутренние API и протоколы которые нигде кроме внутренних компонентов Windows не используются и на совместимость приложений с драйверами не влияют.
Также в ReactOS серьёзные проблемы с процессом разработки и тестированием. Несмотря на большое количество критических багов в ядре и ядерной графической подсистеме, всё это запускают вместе что крайне затрудняет поиск причин багов, падение ядра может быть вызвано порчей памяти в win32k.sys и наоборот. На раннем этапе разработки когда ядро ещё не стабильно, разумно его тестировать отдельно от графики и других компонентов чтобы снизить влияние багов в этих компонентах и локализовать баги ядра.
Тестовые сборки зачем-то настроены как релизные. Кому нужен BSOD в альфа версии нестабильной системы, из которого ничего понять невозможно? Надо сразу при kernel panic показывать на экране отладчик ядра с автоматическим выводом стека как это делает Haiku. Это позволяет сделать фото экрана и отправить разработчикам и не требует от пользователя навыков отладки ядра.
Исправление X512, :
Над реактосью же довлеет проклятие винды.
Никакого проклятия. Там царит карго культ и токсичность (постоянное упоминание как они никому ничего не обязаны, ответы в грубой форме, избыточная бюрократия). Под карго культом я понимаю доскональное воспроизводство Windows там где в этом нет технической необходимости. Например вслед за Windows повторяют ошибку с графической подсистемой в ядре (win32k.sys). Это имело смысл только для совсем слабого железа, сейчас графика прекрасно работает в отдельном процессе пользователя. В том же Wine никаких модулей ядра не требуется. В Windows NT 3.x графика тоже была в процессе пользователя.
Haiku не воспроизводит все внутренние API и протоколы BeOS, например GUI сервер app_server в BeOS и Haiku несовместимы между собой и используют разные протоколы, но кроме системных библиотек этот протокол никто не использует так что несовместимость проблем не вызывает. В ReactOS же зачем-то пытаются воспроизвести все внутренние API и протоколы которые нигде кроме внутренних компонентов Windows не используются и на совместимость приложений с драйверами не влияют.
Также в ReactOS серьёзные проблемы с процессом разработки и тестированием. Несмотря на большое количество критических багов в ядре и ядерной графической подсистеме, всё это запускают вместе что крайне затрудняет поиск причин багов, падение ядра может быть вызвано порчей памяти в win32k.sys и наоборот. На раннем этапе разработки когда ядро ещё не стабильно, разумно его тестировать отдельно от графики и других компонентов чтобы снизить влияние багов в этих компонентов и локализовать баги ядра.
Тестовые сборки зачем-то настроены как релизные. Кому нужен BSOD в альфа версии нестабильной системы, из которого ничего понять невозможно? Надо сразу при kernel panic показывать на экране отладчик ядра с автоматическим выводом стека как это делает Haiku. Это позволяет сделать фото экрана и отправить разработчикам и не требует от пользователя навыков отладки ядра.
Исходная версия X512, :
Над реактосью же довлеет проклятие винды.
Никакого проклятия. Там царит карго культ и токсичность (постоянное упоминание как они никому ничего не обязаны, ответы в грубой форме, избыточная бюрократия). Под карго культом я понимаю доскональное воспроизводство Windows там где в этом нет технической необходимости. Например вслед за Windows повторяют ошибку с графической подсистемой в ядре (win32k.sys). Это имело смысл только для совсем слабого железа, сейчас графика прекрасно работает в отдельном процессе пользователя. В том же Wine никаких модулей ядра не требуется.
Haiku не воспроизводит все внутренние API и протоколы BeOS, например GUI сервер app_server в BeOS и Haiku несовместимы между собой и используют разные протоколы, но кроме системных библиотек этот протокол никто не использует так что несовместимость проблем не вызывает. В ReactOS же зачем-то пытаются воспроизвести все внутренние API и протоколы которые нигде кроме внутренних компонентов Windows не используются и на совместимость приложений с драйверами не влияют.
Также в ReactOS серьёзные проблемы с процессом разработки и тестированием. Несмотря на большое количество критических багов в ядре и ядерной графической подсистеме, всё это запускают вместе что крайне затрудняет поиск причин багов, падение ядра может быть вызвано порчей памяти в win32k.sys и наоборот. На раннем этапе разработки когда ядро ещё не стабильно, разумно его тестировать отдельно от графики и других компонентов чтобы снизить влияние багов в этих компонентов и локализовать баги ядра.
Тестовые сборки зачем-то настроены как релизные. Кому нужен BSOD в альфа версии нестабильной системы, из которого ничего понять невозможно? Надо сразу при kernel panic показывать на экране отладчик ядра с автоматическим выводом стека как это делает Haiku. Это позволяет сделать фото экрана и отправить разработчикам и не требует от пользователя навыков отладки ядра.