Объединенный Открытый Проект

на самом деле драйвера в Виндоус тоже глючат. Так что опираться на драйвера винды, я думаю не стоит.

Sirius, Не совсем. Есть драва, которые пишет Мелкософт. Но суть не много в другом. Тот слой ОС, который отвечает за работу ядра ОС с дровами и железом - реализован очень криво. Так что если Реакт ОС будет передерать организацию работы драйверов, то получится большая Ж****...

Sirius сама концепция этого слоя не правильна. Идея хороша, детальная концепция - полное Г.
Идея синхронной работы естественно более идеальна в отличии от асинхронной (например Unix-Like OS), однако мелко-мягкие и такую идею испоганили!
Если же этот слой и в РеактОС будет писаться по концепции МС, то смысла в нём я не вижу. Многие производители железа и соответственно драйверов к нему ориентируются на справки MSDN, и DotNetAlliance-Journal(нынче уже) ну и соответственно приходится подгонять часть кода под МС.

Поэтому я считаю, что все уровни ОС 21века должны быть не зависимыми друг от друга. Должен быть общий протокол обмена информации, что то типа сокетов.

Кстати говоря, (да простит меня ХХХХПро), советую почитать:
http://www.3os.ru/news.php
http://3os.ru/oven/
http://www.osrc.info/news.php

Вообще-то смысл ReactOS как раз в том и состоит, чтобы разработать эту самую поддержку виндовых драйверов. Если им это удастся, тогда получится свободный софт, поддерживающий эти драйвера, и значит его можно будет приделывать туда, где нужна поддержка этих самых виндовых драйверов.

Какая проблема всегда возникает перед разработчиками принципиально новой оси? Даже если система отлажена и отлично работает, для того, чтобы её мог использовать широкий круг пользователей необходима поддержка их железа. У этих пользователей уже есть свои программы, которыми они пользуются, а у оси - опять же ничего нет. Но как можно в таком случае поступить? Нужна поддержка этик самых драйверов и программ, которые есть у пользователей, а то они врядли полезут туда.

Вот вспомните старый Windows 3.1 и Windows 95. С ними можно было использовать не только их собственные программы и драйвера, но и широкий круг программ и драйверов, которые были в то время наиболее популярны и активно использовались - программное обеспечение для операционной системы DOS.
Теперь посмотрим, как дела с этим обстоят в мире GNU - этот софт часто портабельный (всякий там исключительно WinGNU - это уже неполноценный GNU). Софт этот можно ставить там, где скомпилится. К сожалению GNU не на столько широк, как не GNU, и даже если мы новую ось заполним GNU-шным софтом, этого не всегда хватает. Драйверов опять же не будет - они у каждой оси свои.

А вот теперь представьте себе, что мы можем в нашу ось приделать поддержку программ Windows - сразу же круг программного обеспечения расширится. А если мы добавим ещё и поддержку драйверов? Тогда будет то что надо. Ось работает супер-быстро, супер-безглючно, драйвера работают так же как с виндой, но если хотите более крутых дров - напишите под нашу ось специально (-:

Интересно, а от чего бы вдруг такое мнение? В Windows 95 работали драйвера досовские. Почему мы не можем сделать ось, в которой пойдут виндовые драйвера?

Кстати насчёт небольшого примера из дня сегодняшнего. Знаете есть такая вещь, называется Captive - "the first full read/write free access to NTFS disk drives". Представляет из себя эмуляцию необходимого слоя подсистем ядра Windows NT, что позволяет использовать майкрософтовский драйвер NTFS.
Captive основано на проектах Wine и ReactOS (выдрана часть ядра).
Результат: теперь свободные оси (в первую очередь Linux) могут использовать файловую систему в режиме чтения/записи. Конечно в этом деле всё ещё есть баги и тормоза, но это уже реализация работы с виндовым драйвером из другой операционной системы.

А что нам мешает сделать реализацию такого же captive для других драйверов? На мой взгляд сейчас основная преграда в том, что ReactOS ещё не поднялся до нужного уровня - полно функций-заглушек, ошибок, неоптимизированных частей.

ЭТО НЕ ПОДОЙДЁТ И ДЛЯ ЛИНУКСА!
Т.к. там работа с любыми устройствами организована в асинхронном режиме. Именно из-за этого wine - до сих пор всё и не поддерживает, бывают глюки и тормоза.
Находятся различные способы, что бы для чётко определённой ситуации решить эту проблему. Как бы сказать универсального решения нет.

Кстати,малость оффтоп, но всё же почему-то навеяло: давно блуждает идея создать лёгкий-эмулятор "иной" железки, написать ОС. А затем под любое железо портировать только сам эмулятор.

Разработки ReactOS продолжаются. После того, как было решено не делать почти полной блокировки репозитория и производить разработку одновременно с аудитами, блокируя только отдельные файлы, все разработчики смогли продолжить свою работу.

Если кого-то интерисует, а каковы нынешние успехи - последнюю версию можно взять с SVN - системы контроля версий. Также, если кто хочет присоединиться к разработке - вам туда. Конечно, никто не гарантирует стабильности последней версии в работе. Но разработчики стараются делать так, чтобы это всё дело компилировалось и хоть как-то работало.

Взятую с SVN версию нужно откомпилировать из исхоников. Инструкции про то, как это сделать должны быть на официальном сайте ReactOS. Если не компилируется, а компилятор был правильнопоставлен - можно смело сообщить об этом разработчикам (хотя чаще всего оказывается что просто компилятор неправильно поставили).

wsx Там действительно есть очень большая заморочка с установкой компилятора: нужно не просто поставить MinGW с библиотеками, а потом еще скачать для него какое-то обновление. Я сам с этим долбался немало, пока понял, в чем там дело...

Просто это - рекомендуемый компилятор для ROS (по крайней мере был для версий 0.2.1-0.2.4, сейчас - не знаю). Точнее, это даже не компилятор, а пакет GNU-утилит для Windows (который включает в себя gcc, make, glib и еще много чего), просто он ставится как единый пакет и не такой навороченный, как CygWin (кстати, скомпилировать ROS под CygWin у меня так и не получилось).

К сожалению, в MinGW есть баги. Например, то с чем я стоклунлся - когда собираешь dll-ки толи функции не экспортируются туда, толи не видит проэкспортированные, толи эх лево проэкспортировало.

Вот сейчас у меня на работе - приходится использовать MinGW потому что есть хорошие библиотечки, которые можно только в нём скомпилировать. Под другой компилятор переписать это дело - слишком долго. А потому людям приходится пользоваться тем MinGW, с которым я немного поколдовал полгода назад. С тем, что они сами ставят почему-то ничего не работает.