GPL ReactOS

[turbo]

[size="3"]ReactOS 0.3.6: Релиз[/size]

Эта версия, равно как и все остальные из серии 0.3.x, находится в "альфа" стадии разработки, так что не ждите от релиза слишком многого. ReactOS 0.3.6 - это продукт концентрации текущей разработки на исправлениях ошибок, улучшения совместимости и стабильности. С момента предыдущего релиза прошло более тысячи коммитов в svn-репозиторий ReactOS.

Наиболее важные изменения:

 * Поддержка других архитектур: улучшения в ARM версии, начало поддержки архитектуры x64
 * Уменьшение необходимой загрузчику FreeLdr памяти для загрузки ReactOS
 * Возможность выгрузки драйверов
 * Множество исправлений и улучшения ядра (доставка APC, таймер, большая работа над архитектурно-независимыми частями менеджера памяти)
 * Поддержка большего количества Win32 приложений благодаря исправлению реализации кучи в RTL (например, инсталляторы, основанные на InnoSetup, приложения Delphi, и др.)
 * Исправления ошибок и устранение утечек памяти в сетевом стеке
 * Дальнейшее развитие подсистемы Win32, большинство библиотек DLL режима пользователя синхронизированы с Wine
http://www.reactos.o...ws_page_44.html

[ping_Win]

[size="3"]Вышел релиз ReactOS 0.3.8[/size]

Объявлено о выходе релиза ReactOS 0.3.8, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003). Серия 0.3.x находится в "альфа"-стадии разработки.

Главные новшества релиза:

 * Исправления ошибок и улучшения в базовых сервисах ядра (напр. реестр, примитиы синхронизации такие, как guarded mutex, поддержка ввода-вывода и др.)
 * Дан старт инициативе по исправлению оставшихся двух модулей ядра, дающих больше всего проблем: Менеджер памяти, поддержка кэширования и API драйверов файловых систем, и другого кода, зависящего от Mm
 * Внедрение нового механизма Портируемого SEH (сокращенно PSEH 2.0), который намного ближе по синтаксису и работе к SEH, реализуемому компилятором
 * Исправлено несколько довольно старых ошибок (таких, как проблемы с работой LiveCD при наличии жесткого диска с несколькими разделами, отображение графика загрузки процессора в менеджере задач, и т.п.)
 * Исправления отрисовки графики
 * Реализована минимальная версия протокола KernelDebugger, позволяющая использовать базовую функциональность отладчика MS WinDbg
 * Улучшения в библиотеках CRT и RTL
 * Решён ряд проблем в системных драйверах: NPFS, CDFS, FASTFAT, FS_REC, SCSIPORT
 * Улучшения в видео-драйвере для поддержки реального железа
 * Дальнейшая работа над подсистемой Win32
 * Дальнейшая работа над поддержкой MSVC
 * Исправления в инструментарии для сборки (как часть проекта по поддержке компилятора MSVC)
 * Взаимное обновление базовых утилит и модулей с Wine

Кроме того, был сделан ряд организационных и административных изменений для улучшения процесса разработки: на сайте обновлена индексируемая база исходного кода Doxygen, в дополнение к SVN осуществлено внедрение распределенной системы контроля версий GIT, в которую автоматически зеркалируется дерево разработки ReactOS.

Дополнительно можно упомянуть публикацию русскоязычного отчета о работе проведенной в 2008 году.

http://www.opennet.r...shtml?num=20132

[turbo]

[size="3"]Вышел релиз Reactos 0.3.9[/size]

Представлен релиз ReactOS 0.3.9, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003/Vista). Серия 0.3.x находится в "альфа"-стадии разработки. В рамках инициативы по стабилизации кода для выпуска будущей версии 0.4, все больше сил проект направляет на отладку имеющегося кода и улучшение поддержки программ и драйверов.

Из реализованных новшеств можно отметить:

 * Существенно улучшенный сетевой стек: решены проблемы с работой NDIS и AFD, что улучшило совместимость с драйверами сетевых карт;
 * Добавлена базовая поддержка звука в ядре через сервисы KS ("kernel streaming"). Стало возможным использовать драйвер ac97 через новую библиотеку Port Class для воспроизведения звука используя программу winamp;
 * Снижены минимальные требования памяти до 32 Мб. В теории сейчас ReactOS можно установить имея 24 Мб ОЗУ и запускать всего-лишь с 20 Мб оперативной памяти;
 * В ядре реализован новый, более быстрый интерфейс "Hyperspace Mapping", что дало прирост производительности более, чем на 300%;
 * Улучшения в проверках безопасности в менеджере объектов повышают производительность на 500%. Особенно это заметно при работе с реестром или большими файлами;
 * Большая работа проделана над интерпретатором командной строки, чтобы сделать его более совместимым. Теперь он может исполнять сложные скрипты, включая среду сборки ReactOS Build Environment;
 * Множество улучшений в части библиотеки GDI, работающей в режиме ядра и отвечающей за отрисовку изображений;
 * Синхронизация большинства DLL с проектом Wine.

http://www.opennet.r...shtml?num=21471

[turbo]

[size="3"]Вышел релиз Reactos 0.3.10[/size]

Представлен релиз ReactOS 0.3.10, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003/Vista). Серия 0.3.x находится в "альфа"-стадии разработки. В версии 0.3.10 впервые по умолчанию задействован новый универсальный ATA драйвер, в котором присутствует поддержка SATA и дисковых разделов больше 8 Гб.

Основные улучшения в новой версии:

 * USB стек доработан в плане совместимости с USB клавиатурами и мышами;
 * Устранена невозможность работы с дисковыми разделами, размером более 8 Гб;
 * Добавлена возможность установки на любой из 4 первичных дисковых разделов;
 * Начальная поддержка работы с SerialATA контроллерами;
 * Расширено число поддерживаемых сетевых карт, работа протестирована на 20 разных типах сетевых адаптеров;
 * Проведена работа по увеличению стабильность сетевой подсистемы;
 * В состав включен простой графический редактор, повторяющий по возможностям MS Paint;
 * Начальная поддержка MSVC компиляции;
 * Проведена чистка, связанная с использованием системных ресурсов;
 * Синхронизация большинства DLL и кода подсистемы Win32 с проектом Wine.

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

http://www.opennet.r...shtml?num=22470

[ping_Win]

[size="3"]В Reactos появилась возможность выполнения Kde4 приложений[/size]

Группа итальянских энтузиастов провела адаптацию кода ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003/Vista), для более полной поддержки десктоп-окружения KDE 4.3 и выполнения собранных для платформы Windows KDE-приложений.

Ранее уже предпринимались попытки выполнения окружения KDE 3 в ReactOS, производимые с задействованием пакета Cygwin. Из KDE 4 программ без проблем выполнялись только простейшие приложения, такие как KStars, Kolourpaint, KCalc и KGeography. Отныне пользователи ReactOS получили возможность запуска большинства немодифицированных KDE 4 программ, собранных для Windows, включая Amarok, Okular и Gwenview.

К сожалению, выполнение инсталлятора windows-сборки KDE4 в ReactOS приводит к сбою, поэтому для подготовки демонстрации энтузиасты вначале установили KDE4 под Windows, а потом скопировали бинарные файлы в ReactOS.

http://www.opennet.r...shtml?num=23166

[ping_Win]

[size="3"]Вышел релиз ReactOS 0.3.11[/size]

Объявлено о выходе релиза ReactOS 0.3.11, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003). Серия 0.3.x находится в "альфа"-стадии разработки.

Из основных изменений отмечается полная переработки системы управления памятью и значительное расширение возможностей звукового стека. В системе управления памяти добавлена поддержка процессоров ARM. Блок управления памятью (MMU) в ARM работает принципиально иначе, чем в архитектурах x86 и x86-64, тем не менее разработчики постарались как можно сильнее унифицировать код. В звуковой подсистеме появилась поддержка записи звука, реализация микшера с возможностью управления уровнями громкости, увеличения совместимости звукового стека с Windows XP.

Некоторые другие улучшения, реализованные в новой версии:

 * Улучшение совместимости системы с интерфейсом WinDbg, позволяющим выполнять отладку на уровне ядра системы. В новой версии появилась поддержка пошаговой отладки ядра, просмотра нитей процессов и динамического редактирования областей памяти;
 * Полная переработка библиотеки kdcom с целью улучшения совместимости с версией от Microsoft;
 * Поддержка отложенной загрузки DLL;
 * Проведена работа по обеспечению совместимости с компилятором GCC 4.4;
 * Поддержка корейских и китайских шрифтов. Стандартные шрифты DejaVu обновлены до версии 2.30 ;
 * Добавлен новый обработчик для установки и чтения системных параметров (SystemParametersInfo API), который значительно более совместим с Windows, чем прошлая реализация;
 * Улучшена совместимость с такими приложениями, как Opera, Open Office, Firefox 3.5, VLC1.1 и Skype;
 * В комплект добавлена новая игра Spider Solitaire;
 * Проведена синхронизация большинства DLL и кода подсистемы Win32 с проектом Wine.

http://www.opennet.r...shtml?num=24697

[Drone]

[size="3"]Вышел релиз ReactOS 0.3.11[/size]

Это же каким интузиазмом нужно обладать чтобы писать этот проект! Когда впервые появилось сие я даже добросовестно затестировал, но только будущего у ReactOS нет это точно. Кому нужна полу-, да что там, одна четвертая винды хоть и с исходным кодом.

[turbo]

[size="3"]Координатор ОС ReactOS предложил перейти на единую с Wine Win32-подсистему[/size]

Алексей Брагин, один из ведущих разработчиков ReactOS, предлагает (перевод) поменять способ разработки этой операционной системы. По его словам, за 10 лет развития проекта ReactOS он все ещё не достиг состояния, в котором его можно было бы реально использовать.

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

В связи с этим Алексей разработал совершенно новую концепцию развития ReactOS - Arwinss (PDF, 895KB), которая подразумевает разработку этой ОС как неотъемлемой части проекта Wine, что позволит избежать огромной работы по портированию библиотек Wine/Win32 в ReactOS. В частности, в ReactOS из Wine без изменений будут использованы такие библиотеки, как USER32.DLL и GDI32.DLL.

http://www.opennet.r...shtml?num=25051

[ValeryK]

В связи с этим Алексей разработал совершенно новую концепцию развития ReactOS - Arwinss (PDF, 895KB), которая подразумевает разработку этой ОС как неотъемлемой части проекта Wine, что позволит избежать огромной работы по портированию библиотек Wine/Win32 в ReactOS. В частности, в ReactOS из Wine без изменений будут использованы такие библиотеки, как USER32.DLL и GDI32.DLL.

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

[Iskander]

[size="3"]Координатор ОС ReactOS предложил перейти на единую с Wine Win32-подсистему[/size]

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

[Zhek@Ch]

[size="3"]GPL ReactOS 0.3.12: Состоялся долгожданный релиз [/size]

После 11 месяцев разработки представлен релиз ReactOS 0.3.12, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003/Vista). Серия 0.3.x находится на "альфа"-стадии разработки. Из наиболее значительных улучшений можно отметить:

• Продолжается работа над новым менеджером управления распределением памяти. Большая работа проделана для обеспечения поддержки платформы ARM. Хотя в настоящий момент ReactOS еще не полностью переведен на новый менеджер памяти, но уже в текущем релизе можно наблюдать такие отголоски новой модели, как увеличение стабильности, скорости и совместимости;
• Добавлена поддержка обработки немаскируемых прерываний (NMI).В случае обнаружения аппаратных проблем, обнаруженных процессором или шиной, теперь выявится "красный экран смерти". Для серверных систем интегрирована поддержка подключения внешних обработчиков NMI. Начата, но еще не доведена до конца, возможность генерации crash-дампа со срезом данных на момент генерации NMI (например, может оказаться полезным для выявления причины зависания, если система поддерживает возможность ручной генерации NMI).
• Полностью переработан механизм обработки ловушек (trap), что привело к переписыванию ощутимой части ядра системы. Теперь весь код, обрабатывающий сбои CPU, трапы, исключения и системные вызовы переписан с ассемблера на язык Си. В итоге, код стал более ясным и надежным. Возможные потери производительности с лихвой компенсируются средствами оптимизации Си-компилятора, способного учитывать особенности различных аппаратных архитектур при генерации кода (вручную написанный ассемблерный код учитывал особенности всего нескольких моделей CPU). Другое достоинство - увеличение объема кода, который можно использовать одновременно для архитектур x86 и ARM. Также удалено много устаревшего кода и отключен по умолчанию отладочный код, оказывающий негативный эффект на производительность. В будущем будет продолжен процесс перевода на язык Си процедур, написанных на языке ассемблера.
• Частично реализован режим экстренного управления системой (Emergency Management System), при котором поддерживаются совместимые с Windows загрузочные флаги, возможен вывод отладочной информации через последовательный порт и запуск отладчика. В разработке находится драйвер административной консоли (Special Administration Console);
• Проведена работа по увеличению совместимости PnP-подсистемы с оборудованием и по реализации возможности загрузки драйверов, от сторонних производителей;
• Улучшение в поддержке ACPI - для платформы ARM реализованы базовые драйверы, необходимые для поддержки контроля аккумуляторов и UPS. Добавлен код для поддержки спецификации ACPI Composite Battery, который пока отключен по умолчанию;
• Добавлен новый драйвер шины PCI-X. Ранее в ReactOS использовался достаточно примитивный и устаревший драйвер, не поддерживающий многие современные возможности PCI-шин и PCI-to-PCI мостов. С новым драйвером значительно увеличена совместимость с реальным оборудованием и увеличена производительность;
• Добавлена поддержка технологии Side-by-side (WinSxS), позволяющей избавиться от проблем с организацией загрузки DLL-библиотек (конфликты версий, отсутствие DLL, дубликаты DLL, некорректная регистрация DLL);
• Переписан код обработки сообщений и работы с таймером, что позволило избавиться от ранее возникавших взаимных блокировок в некоторых приложениях, некорректно обрабатывающих не поставленные в очередь сообщения. Переработка кода таймера позволила избавиться от таких проблем, как "необходимость пошевелить мышь чтобы сработала загрузка в Firefox";
• На начальной стадии находится развитие порта для 64-разрядных систем: решены основные проблемы сборки, реализована самая необходимая базовая функциональность;
• Исправлено 259 ошибок, включая более 60 регрессивных изменений, некоторые из которых тянутся еще с релиза ReactOS 0.3.7. Десять ошибок оставались неисправленными на протяжении более трех лет, а одна из ошибок оставалась неисправленной 5 лет.

[Zhek@Ch]

[size="3"]Команда ReactOS рада сообщить о выпуске ReactOS 0.3.13[/size]
 
ReactOS -- свободная и бесплатная операционная система, совместимая с приложениям и драйверами ОС Windows.

Вот некоторые из наиболее важных изменений:

• добавлена возможность динамической смены видеорежима и улучшена совместимость видеодрайверов;
• исправлено несколько проблем с отображением графики;
• полностью переписан диспетчер кучи, в него были добавлены дополнительные возможности отладки для обнаружения доступа к памяти вне границ выделенного для производимой операции блока;
• улучшено управление линиями аудиомикшера, что позволило исправить искажение звуков приложений из-за наложения сигналов;
• произведено значительное количество исправлений в пользовательской подсистеме (улучшена обработка данных от мыши, а также поддержка сообщений и таймеров);
• исправлены визуальные артефакты в некоторых приложениях, например, в Firefox и Thunderbird;
• исправлен ряд ошибок в программе установки;
• улучшена совместимость с приложениями: Stellarium 0.10.2, LHelp, winpcap, FlashPlayer 10.1, Mono 2.8, OllyDbg 1.10, Xenon 2000, VLC 1.1.5, Foobar 2000 и Skype 4.0.0 теперь полностью работоспособны;
• увеличено количество поддерживаемых SATA-устройств;
• исправлены ошибки прохождения множества контрольных тестов;
• произведено множество улучшений в диспетчере памяти, что привело к устранению нескольких ошибок и сделало его более совместимым с диспетчером памяти NT.

>>> Подробности

# linux.org.ru

[Zhek@Ch]

[size="3"]ReactOS поборется за государственные инвестиции. [/size]
 
Операционная система ReactOS, а точнее стартап-компания WooSNet примет участие в Зворыкинском Проекте, а так же весьма вероятно будет представлен на Селигере 2011. WooSNet -- коммерческая компания, которая будет спонсировать разработку ReactOS и использовать ReactOS в качестве основы для реализации своих продуктов, направленных на бизнес-сектор и правительственные учреждения. Стоит заметить, что продукты под брэндом WooS (читается как «вус») будут также открытыми и бесплатными, а бизнес модель компании строится на предоставлении сервисных, сертификационных и иных услуг. Разработчики ReactOS просят поддержать проект, проголосовав за него, оставив комментарий или альтернативное описание проекта "своими словами" на сайте http://www.innovater...ect/front/21013 (к сожалению, потребуется регистрация)

Алексей Fireball Брагин:

В этот раз это не BolgenOS http://linuxforum.kz/public/style_emoticons/<#EMO_DIR#>/smile.gif\' class=\'bbc_emoticon\' alt=\':)\' />. Это действительно наш эксперимент по привлечению реальных денег для вывода ReactOS на новую стадию разработки и использования. Уже есть поддержка из Испании, но т.к. проект очень амбициозный и большой, а местного Шаттлворта у нас нету, то решили действовать по действительно международному сценарию, привлекая инвесторов из разных стран.

 Что касается взаимоотношений WooSNet с ReactOS, то они самые прямые. Начиная с меня, и заканчивая тем, что при получении инвестиций WooSNet будет напрямую спонсировать разработку ReactOS, т.к. от этого зависит успешность бизнеса. Нет ОС -- нет и бизнеса. WooSNet - это бренд, под которым будут выпускаться продукты. Как Ubuntu -- это бренд для Debian Linux от Canonical, тоже самое Woos -- бренд для ReactOS от WoosNet.

 >>> РеактОС на Зворыкинском Проекте.

# linux.org.ru

[Zhek@Ch]

[size="3"]Перевод 85 выпуска новостей проекта ReactOS [/size]

Доступен перевод 85 выпуска новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003).

В выпуске:

• Поддержка тем оформления Яннис завершил разработку поддержки прорисовки в большинстве зон окна, включая заголовки, границы и полосы прокрутки. Наиболее сложными в разработке оказались полосы прокрутки, поскольку программный код, обрабатывающий расчёты при прокрутке, также отвечает за перерисовку изменений содержимого соответствующего окна. Он представлял собой крайне печальное зрелище, состоящее из многократно повторяющихся больших частей кода прорисовки внутри функции обновления окна при прокрутке его содержимого. Из-за этого удобочитаемость кода значительно снизилась, однако Яннис пока не видит другого возможного решения этой проблемы.

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

• Поддержка отладки Проект ReactOS в прошлом имел склонность создавать собственные решения для различных своих нужд, несколько из которых используются уже довольно давно. В качестве двух самых ярких примеров можно назвать систему для сборки ReactOS на основе rbuild и систему управления содержимым RosCMS, используемую на вебсайте. Ещё одним инструментом, дошедшим до нас из ранних дней проекта, является свой формат отладки под названием rsym. Проще говоря, rsym предоставляет лишь чуть больше информации, чем просто номер строки, содержащей конкретную инструкцию, для чего rsym использует информацию о номерах строк, предоставляемую ему GCC по умолчанию.

Первоначальным намерением его создателей могло быть желание сделать ядро достаточно компактным, чтобы оно могло поместиться в память на ранних этапах загрузки. Информация о номерах строк, которую добавляет GCC в формате stabs, значительно увеличивает размер получаемого двоичного файла, а rsym представлял собой способ добавить данные о номерах строк и не получить при этом многомегабайтный двоичный файл. Однако уже существует достаточно компактный формат отладочных символов, предоставляющий гораздо больший объём информации, чем просто номера строк кода. Речь идёт, разумеется, о формате отладочных символов DWARF и Арт Йеркс (Art Yerkes) работал над добавлением его поддержки в kdbg, инструмент для отладки ядра, используемый нашими разработчиками, а также в систему автоматического тестирования сборок.

Арт сделал значительную часть работы, необходимой для обеспечения разработчиков возможностью используя DWARF получать значения аргументов, передаваемых функциям. Как только остальная часть работы будет закончена, проект сможет полностью отказаться от использования rsym и намного улучшить поддержку отладки ядра и других компонентов ReactOS без значительного изменения размера двоичных файлов.

• Драйвер диспетчера монтирования Стек запоминающих устройств эры NT5/6 состоит из нескольких компонентов, и каждый из них имеет своё назначение. Драйвер диспетчера монтирования mountmgr, как следует из его названия, отвечает за монтирование устройств и регистрацию их в пространстве имён устройств операционной системы, что позволяет ей использовать их самостоятельно и предоставить доступ к ним пользователю. В архитектуре NT4 этим занималось ядро системы. В этом отношении архитектура NT4 в ReactOS соблюдалась достаточно точно до тех пор, пока Пьер Швейцер (Pierre Schweitzer) не начал работу над нашей собственной реализацией драйвера mountmgr.

Одной из дополнительных особенностей mountmgr является возможность смонтировать том в виде каталога, так же, как в Linux. К сожалению, данная функциональность требует более совершенной файловой системы, чем FAT, поэтому пройдёт ещё довольно много времени, прежде чем мы сможем использовать эту возможность в ReactOS. Остальная часть стека хранения просто регистрирует обратные вызовы к диспетчеру plug-n-play для уведомления его о монтировании нового тома.

Другие драйверы в стеке запоминающих устройств также необходимо обновить для их взаимодействия с драйвером mountmgr, хотя если их обновление невозможно, уведомления для этих драйверов вполне можно сфальсифицировать. Йоханнес Андервальд (Johannes Anderwald) особенно заинтересован в результатах этой работы, поскольку это очень важный элемент в головоломке поддержки накопителей для порта USB.[/list]

# opennet.ru

[Zhek@Ch]

[size="3"]86 выпуск новостей проекта ReactOS [/size]

Доступен перевод 86 выпуска новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003).


Прогресс в использовании компилятора MSVC
 
Код ReactOS теперь может быть полностью собран с использованием компилятора Microsoft, но работать после такой компиляции операционная система пока ещё не способна. Тимо Кройцер (Timo Kreuzer) уже устранил несколько ошибок, среди которых повреждение метаданных файловой системы, приводившее к неработоспособности загрузчика freeldr. На платформах x86/x64 в процессе начальной загрузки в таблицу FAT c диска считывается загрузочный сектор, который должен быть загружен в достаточно высокие адреса, чтобы дальнейшее чтение freeldr в память позже не перезаписало бы эту таблицу. К сожалению, скомпилированная в MSVC версия freeldr занимает больше места, чем при компиляции с использованием GCC, что приводило к перезаписи таблицы FAT. Когда начальный загрузчик пытался запросить таблицу FAT, чтобы понять, нужно ли загрузить ещё что-то, он получал код freeldr вместо данных и предполагал, что необходимо загрузить дополнительные данные. Однако попытка использовать данные freeldr в качестве инструкции по загрузке, приводила к выводу ошибки и невозможности загрузить freeldr. Тимо устранил эту проблему, изменив адреса, куда загружается таблица FAT, чтобы гарантировать цельность данных при использовании файлов, скомпилированных с помощью MSVC.

Другая проблема, связанная с файловой системой, была найдена в драйвере именованного канала (pipe). Драйвер поддерживает связанный список клиентских блоков управления (CCB), доступ к которому синхронизируется с использованием блокировки (lock). Однако существовал способ получить доступ к CCB без установки блокировки, что могло привести к эффекту гонки (race condition). Например, при определенном стечении обстоятельств один поток мог удалить запись в списке CCB, но ссылка на этот удаленный элемент могла в это время использоваться в другом потоке. Решение Тимо состояло в использовании счетчика ссылок, с последующим отслеживанием числа активных экземпляров ссылок к элементам CCB, чтобы препятствовать удалению еще занятых элементов CCB. Эта проблема также существовала и в сборке GCC, но была более достоверно воспроизведена в сборке MSVC.


Устранение ошибок сети
 
Хрупкость сетевого стека ReactOS иногда трудно понять не-разработчикам, но список проблем, который был недавно разрешен Камероном Гутманом (Cameron Gutman), должен дать представление о том, как много частей работало неправильно. Камерон обратил свое внимание на то, что многие сетевые тесты завершаются провалом. В результате трассировки некоторых сбойных тестов было выявлено использование некорректной семантики при работе с кодом обработки событий. Если программа сообщает ОС, что она ожидает определенное событие, но событие при этом было уже инициировано или инициировано прежде, чем ОС фактически вызывает функцию ожидания, ОС, как предполагается, сразу запускает программу, как только будет выполнен вызов ожидания события. Это не было сделано, что приводило к тому, что запрашивающие уведомление о событии программы в некоторых ситуациях зависали, прежде, чем могли сделать что-либо еще.

Другая проблема с событиями связана с неправильной установкой полномочий для событий. События обычно создаются с уровнем разрешения EVENT_ALL_ACCESS. Однако, когда программа попыталась получить доступ к событию, код ОС пытается получить доступ к событию с уровнем разрешения FILE_ALL_ACCESS. Это не одно и то же: у FILE_ALL_ACCESS есть несколько полномочий, которых нет у EVENT_ALL_ACCESS, что должно приводить к ошибке доступа. С этим исправлением будет налажена отправка сигналов о наступлении событий, и приложения, которые ранее зависли на сетевых запросах, теперь должны работать нормально.

Помимо уведомления о событиях сетевой активности, было найдено несколько серьёзных семантических ошибок в обработке соединения TCP, реализованных в некоторых частях сетевого стека. Функции recvfrom и sendto обрабатывали соединения TCP так, как если бы они были соединениями UDP. Достаточно сказать, что это просто никак не работало. Единственной причиной, по которой данная ошибка не затронула большинство пользователей, является немногочисленность приложений, использующих функции recvfrom и sendto с соединениями TCP, вместо которых обычно используются функции recv и send. Как ни парадоксально, recv работал неправильно с соединениями UDP, и снова ошибки не возникали только потому, что большинство приложений использует для UDP функцию recvfrom. Исправление должно помочь справится с теми случаями, когда приложения не соблюдали выше описанные негласные правила.

Еще один набор проблем был связан с особенностями завершения работы сетевых соединений в используемой в ReactOS библиотеке oskittcp. Протокол "рукопожатия" (handshake) в TCP предусматривает использование пакетов с флагом FIN для информирования удаленной стороны о завершении передачи данных. Вызов функции "shutdown(SD_SEND)" генерирует пакет FIN, но должен все еще оставить соединение открытым для чтений. К сожалению, библиотека oskittcp не делала этого и полностью закрывала сокет, что приводит к невозможности выполнения операций чтения из сокета после вызова функции завершения отправки данных. Заключительная проблема, которую устранил Камерон, также была связана с oskittcp. В частности, из-за данной библиотеки не происходило информирование ОС о сбоях соединения. После решения данной ошибки сетевой стек ReactOS проходит значительно больше тестов и стал более пригоден к использованию. Одновременно, проблемы в oskittcp подталкивают разработчиков к миграции на альтернативную библиотеку lwip.

# opennet.ru

[Zhek@Ch]

[size="3"]88 выпуск новостей проекта ReactOS [/size]

Доступен перевод 88 выпуска новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003).


Shell32

 Ещё одним достижением Клаудиу Михаила (Claudiu Mihail), который в рамках недавнего Google Summer of Code преобразовал библиотеку IwIP в драйвер, стало окончание работ по переписыванию библиотеки shell32 с языка C на C++ и интеграция полученного программного кода в транк. Работы по преобразованию были начаты Гедом Мёрфи (Ged Murphy) и Эндрю Хиллом (Andrew Hill), и цель их проведения состояла в том, что C++ наилучшим образом подходит для реализации различных аспектов механизма COM в этой библиотеке. Сначала Гед попытался сконвертировать код непосредственно в транке, однако оказалось, что в этом случае поддерживать целостность кода в транке весьма сложно, и Гед переместил свои наработки в отдельную ветвь. Клаудиу, после завершения своего проекта GSoC, продолжил его работу и доработал код.

Перевод кода с C на C++ нередко выявляет ошибки в коде, такие например, как не заданные значения по умолчанию для элементов класса в конструкторе или некорректно выполненные обновления элементов класса. Одной из самых больших проблем, требовавших исправления, являлось то, что апплеты Панели управления не запускались. Эта проблема возникла после того, как Клаудиу внёс исправления в парсер командной строки для обеспечения прохождения тестов Wine. Парсер корректно уменьшал названия апплетов до их короткой формы, например с "Add Hardware" до "Add", однако из-за проблемы в глубине кода библиотеки, система не могла найти апплеты Панели управления по их коротким именам.

Когда эта проблема была устранена, оказалось, что из-за других ошибок в библиотеке ATL невозможна правильная регистрация расширений в оболочке. Яннис Адамопулос (Giannis Adamopoulos) тоже обращал внимание на проблемы с регистрацией, но так и не смог решить их. Кроме того, Йоханнес Андервальд (Johannes Anderwald) также тщетно пытался справиться с этой проблемой, и заявил, что ATL является неподходящим механизмом для регистрации расширений оболочки. Тем временем Амин Хальди (Amine Khaldi) сделал откат изменений в коде регистрации, что позволило использовать старый механизм регистрации, взятый из Wine и являющийся хоть и архитектурно неправильным, но, по крайней мере, хоть немного работоспособным.

Поскольку корректная реализация shell32 никогда не являлась приоритетной задачей для Wine, то и тестов в наборе winetests для проверки этого компонента очень мало. Клаудиу работает над этим и уже добавил несколько новых тестов для проверки большего количества функций библиотеки. Совместно с Виктором Мартинесом (Victor Martinez) было добавлено несколько тестов для проверки парсера командной строки, а тесты для других составных частей библиотеки, надеемся, скоро также появятся.


Исправления в загрузчике

 Прошло уже несколько месяцев с тех пор, как Алексей Брагин добавил в основную кодовую базу результаты своей работы по переписыванию загрузчика, что привело к появлению в системе большого количества регрессий. Однако, как минимум одна из регрессий была связана с маркерами безопасности (security cookies). Они не имеют ничего общего с cookies, используемыми при интернет-сессиях, а предназначены для вызова соответствующих функций для обнаружения повреждений памяти. Повреждения памяти и тому подобные проблемы могут произойти как в стеке, так и в куче. Тем, кто не знает, чем стек отличается от кучи, вкратце можно пояснить, что стеком называется то место, где хранятся все локальные переменные функций, в то время как куча представляет собой источник динамически распределяемой памяти.

При вызове какой-либо функции происходит переход в другую часть памяти, где хранится код этой функции. Для возвращения из кода закончившей работу функции обратно к коду программы, вызвавшему эту функцию, необходим адрес, из которого произошёл её вызов. Этот адрес является частью стека функции, и, если в стеке по какой-либо причине произойдёт переполнение буфера, адрес будет перезаписан неверными данными. Маркер помещается перед адресом, и любое изменение его значения служит верным признаком повреждения стека. Если адрес был повреждён, операция, которая его повредила, также должна была изменить и значение маркера.

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


Отладочный пул

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


Инфраструктура

 Благодаря опыту работы с другими проектами, Пьер Швейцер (Pierre Schweitzer) решил попытаться пропустить исходный код ReactOS через утилиту статического анализа cppcheck, и посмотреть что из этого получится. В результате от него стройным потоком пошли исправления утечек памяти, как непосредственно в ReactOS, так и в разработанных для него инструментах и приложениях, включая уходящий на заслуженный отдых RBuild. Сейчас, для существенного ускорения сканирования, Пьер не подвергает анализу файлы заголовков основных программ, драйверов, а так же родных инструментов разработки.

Команда также усердно работала над объединением всех частей новой среды сборки на основе CMake, готовясь к отказу от RBuild. Первоначально разработчики намеревались включить в среду сборки ещё и GCC 4.6, но способ, которым в GCC toolchain экспортируются различные встроенные функции, доставил им немало проблем и помешал переключиться на использование GCC. У ReactOS имеются собственные встроенные функции, а их экспорты находятся в библиотеке kernel32, но экспорты GCC находятся в его библиотеке mingwex. В результате, компоновщик обнаруживал два одинаковых экспорта для одной и той же функции, что приводило к сбою компоновки бинарных файлов. Кроме того, версия среды сборки для Windows будет использовать для установки MSI взамен NSIS, это долгосрочная задача для Даниэля Реймера (Daniel Reimer), который занимается разработкой среды сборки для Windows.

Сборки CMake начали собираться на Windows-машинах, обслуживаемых Олафом Сейкой (Olaf Siejka) ещё некоторое время назад, и команда в настоящее время работает над возможностью сборки и тестирования ReactOS в системе Linux.


Ввод с клавиатуры

 В прошлом году Яннис работал над поддержкой сообщений от мыши. В этом году, Рафал Харабиен (Rafał Harabień) решил заняться клавиатурной частью поддержки устройств ввода. Для определения того, какая клавиша была нажата, клавиатура отправляет на компьютер скан-код. Эти скан-коды затем обрабатываются с учётом используемой раскладки клавиатуры, таким образом операционная система и приложения узнают, какую букву или специальную виртуальную клавишу нажал пользователь. Как и в немалой части других компонентов ReactOS, в коде поддержки клавиатуры содержалось немало проблемных мест. В системе имелись жёстко прописанные в коде значения для некоторых скан-кодов, из-за чего нажатия обрабатывались без учета выбранной пользователем раскладки, что нарушало совместимость с любыми раскладками, пересекающимися с жёстко прописанными скан-кодами. Рафал переписал код для обеспечения корректного маппинга на уровне раскладок клавиатуры и намеревается продолжить ранее начатую Яннисом работу по слиянию потоков событий от мыши и клавиатуры в единый поток ввода. Он также планирует решить проблемы с подключением нескольких клавиатур и обеспечить прохождение тестов Winetests, связанных с клавиатурой и мышью.

# opennet.ru

[Zhek@Ch]

[size="3"]Интервью с Алексеем Брагиным, координатором проекта ReactOS [/size]

Алена Попова, основатель проекта Duma 2.0, популяризатор систем электронного правительства и инвестор в высокотехнологичные проекты, опубликовала в своём блоге видеоинтервью с Алексеем Брагиным, координатором проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003). В интервью в основном затрагиваются вопросы популяризации системы и таких особенностей, как открытый процесс разработки и независимость от отдельных производителей.

# opennet.ru