ROS Newsletter63

Выпуск новостей ReactOS №63

• Публикация в архиве

Тестирование сбоев

В течении нескольких дней набор программ для автоматического тестирования ReactOS намертво зацикливался во время прохождения теста msi_winetest. Несколько человек во время тестирования обратили внимание на эту проблему и предположили возможные причины зависания, в итоге Джефри Морлэн [Jeffrey Morlan] написал патч, который, похоже, исправил баг. Проблема проявлялась в функции LoadLibraryExW, в тех случаях, когда был установлен флаг LOAD_LIBRARY_AS_DATAFILE. Во время вызова в функцию передавался параметр DllName – название библиотеки, которую требовалось загрузить. Если в названии были пробелы, функция делала локальную копию, в которой они вырезались. Как только функция заканчивала свою работу, то она освобождала память, выделенную под эту локальную копию. Однако, код, написанный Дмитрием Чапышевым, пытался освободить память независимо от того, выделялась она или нет. В случае отсутствия в строке пробелов, попытка освободить память вызывала повреждение данных и приводила к бесконечному циклу. Джефри исправил эту ошибку и набор тестовых программ больше не приводит к подобной проблеме. Хотя казалось, что причину зависания в наборе программ для тестирования не определить, он провел оперативную работу по выявлению данной ошибки. С другой стороны, эта ошибка могла долго оставаться незамеченной и позднее могла привести к более серьезным последствиям.

Исправления для MSVC

Стефан Гинсберг[Stefan Ginsberg] стал проверять модуль за модулем ReactOS, чтобы согласовать многочисленные несоответствия синтаксиса, которые мешают использованию MSVC для компиляции ReactOS. GCC намного гибче, чем MSVC в структуре синтаксиса кода. В результате, определенные соглашения в коде ReactOS приемлемы для GCC, но в то же время заставляют спотыкаться MSVC. Например, определение прототипов функции, размещение и группировка типов отклика и соглашения о вызовах различаются. MSVC требует, чтобы соглашение о вызовах и имя функции были явно отделены в скобки, тогда как GCC этого не требует. Этот конкретный пример присутствует во всех фрагментах кода, но к счастью его довольно легко найти и устранить.

Более неприятная проблема возникла в связи с тем, что GCC не предупреждал о функциях, вызывающих самих себя. Использование таких рекурсивных вызовов возможно, но не в этом случае, так как это приводит к бесконечному рекурсивному вызову. Проблема порождена заголовками в w32api, которые используются в mingw для разработки Windows. Например, в заголовке функция ExAllocatePoolWithQuotaTag была определена как ExAllocatePoolWithQuota. Это вызвало очень неприятную ситуацию, поскольку ExAllocatePoolWithQuota это просто вызов функции ExAllocatePoolWithQuotaTag, так как одна функция служит как оболочка для другой. Код, который был откомпилирован с использованием таких заголовков и пробовал использовать функцию ExAllocatePoolWithQuotaTag, вероятно застревал в бесконечном цикле, в конечном счете исчерпывая стек и вызывая "синий экран". Компилятор MSVC указал на эту проблему и выдавал предупреждение даже на самом низком уровне уведомлений, тогда как GCC не обращал на это внимания.

ARWINSS возвращается

Похоже, что отсутствие информации о предназначении подпроекта ARWINSS сбило многих с толку, так как они приняли его за замену подсистемы Win32, чем на самом деле ARWINSS не является. Поскольку цель этого подпроекта не была ясно выражена, возникли некоторые весьма необычные предположения. В свете этих событий Алексей Брагин заявил, что ARWINSS – всего-навсего временная мера, призванная использовать в наших интересах достижения Wine в запуске приложений Windows, чтобы расширить функциональную базу ReactOS. Многие помнят как около года назад Алекс Айонеску (Alex Ionescu) фактически переписал ядро, что привело к массивным поломкам и багам, в следствие чего работа над системой была остановлена до полного совместного устранения ошибок. Изменения были крайне необходимы, но остальная часть системы запиналась, когда требовалось корректно использовать различные службы. Фактически, исправление подсистемы Win32 потребовало бы подобного уровня регрессии из-за серьёзных проблем в критических компонентах. И Джим Тэбор (Jim Tabor) и Тимо Креузер (Timo Kreuzer) делали всё возможное чтобы при внесении изменений в систему свести регрессии к минимуму, но это равносильно сражению на два фронта. Что, с точки зрения пользователей, было бы неприемлимо. Кое-что в системе нуждается в серьезном рефакторинге и изменении, и именно для этого может использоваться ARWINSS. Будет ли проект существовать достаточно долго, покажет время. Однако, его различия с основным кодом могут позволить эксперименты, невозможные в текущей версии подсистемы Win32.

Даже помня об этом, не все согласны с необходимостью ARWINSS. Вначале несколько разработчиков подумали, что Алексей пытается заменить подсистему Win32 во всей ветке и очень холодно приняли эту инициативу. Даже после прояснения ситуации, существует проблема, что ARWINSS может отвлечь внимание от текущей переработки кода. Это говорит о том, что ARWINSS поднимает некоторые интересные проблемы в пределах операционной системы в целом. Конечно, мы надеемся, что ARWINSS окажет позитивное влияние на проект, но насколько это так покажет время.