ROS Newsletter73

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

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

Таймеры и сообщения

Несколько лет назад, когда я присоединился к команде ReactOS в качестве специалиста по выпуску релизов (технически, я до сих пор им являюсь), команда столкнулась со странной ошибкой. Для того, чтобы загружались web-страницы в Firefox, необходимо было двигать мышь. Джим Табор (Jim Tabor) выяснил, что причина проблемы заключается в том, как в ReactOS реализованы таймеры, из чего следовало, что решение, скорее всего, будет непростым. Несколько лет спустя он закончил основную часть кода новой реализации таймеров, а Михаэль Мартин (Michael Martin) внёс несколько дополнительных исправлений, чем обеспечил её функционирование.

Ранее, система могла проверить истечение таймера Win32k только получив системное сообщение от приложения из очереди сообщений. Эти сообщения обычно являются уведомительными и посылаются операционной системой приложению, чтобы проинформировать его о каких-либо событиях, например, о перемещении мыши. Это означает, что система никогда не проверяла, истекло ли время таймера, если не было никаких сообщений или событий. Firefox выявил эту ошибку, поскольку предусмотрительно пытался избежать опроса, происходящего обычно в приложениях Win32, переходя в спящий режим и пробуждаясь по таймеру. Исправления Джима связаны с использованием таймера ядра, который по истечении времени заставляет систему проверить на истечение существующие таймеры win32k.

Консоли и BSOD

Консоли в Windows одновременно могут иметь несколько экранных буферов, однако, возможно, из-за того, что количество приложений, реально использующих эту возможность, не велико, о ней часто забывают. Также, как и на различных производных Unix, приложение загружает содержимое файла в новый буфер и при выходе пользователя перемещает его туда, где он находился изначально. Ранее, консоли и буферы экрана в ReactOS учитывались отдельно, и не было ничего, что связывало бы неактивный буфер экрана и породившую его консоль. Это создавало любопытную ситуацию, когда простое переключение между несколькими буферами экрана одной консоли не имело никакого смысла. Хуже того, если консоль была закрыта при помощи функции FreeConsole, буферы экрана, которые могли быть ей созданы, не очищались, поэтому новая консоль, созданная при помощи функции AllocConsole, могла подключиться к ним. Помимо утечки ресурсов, эта проблема при соответствующем использовании может стать стать потенциальной угрозой безопасности.

Джеффри Морлан (Jeffrey Morlan) переработал механизм управления буферами, добавив связанный список в объект консоли, благодаря которому она может отслеживать буферы, которыми владеет. В то же время, он добавил ссылку на родительскую консоль в сами буферы. Эти изменения позволяют функции FreeConsole узнать о буферах, которыми владеет закрываемая консоль, и удалить их, закрыв тем самым эту дыру. В процессе исправления этой проблемы, он столкнулся с ошибкой в самой Windows, где удаление последнего буфера в еще активной консоли и попытка заставить её переключиться к уже несуществующему буферу приводит к критическому сбою операционной системы. Разумеется, такое поведение операционной системы Джеффри эмулировать не собирался, и в настоящее время вполне удовлетворён ситуацией, когда консоли, вплоть до её закрытия, принадлежит хотя бы один буфер.

Управление сокетами

Кэмерон Гутман (Cameron Gutman) в течение всего прошлого месяца продолжал работу над сетевым стеком. Одной из наиболее сложных проблем, решённых им, стал способ хранения компонентом msafd информации о сокете. Изначально, все данные находились в статичном массиве ёмкостью в 1024 элемента, который фактически гарантировал переполнение буфера, если приложение открывало более, чем 1024 сокета. В дополнение ко всему структура, используемая для хранения информации о сокетах, никогда не освобождалась, даже если приложение заканчивало работу с ней. В совокупности, эти две проблемы могли бы стать основным препятствием в масштабируемости ReactOS.

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

Arwinss: возвращение и дальнейшее развитие

За последний месяц в Arwinss было произведено три значимых изменения, продемонстрировавшие сложности, связанные с повышенной зависимостью этой ветки от Wine. Первое изменение связано с желанием проекта Wine почистить код поддержки курсора мыши, сделать его более совместимым и удалить некоторые из последних остатков 16-битного кода. Следует напомнить, что изначально Wine был задуман как попытка скопировать API 16-разрядной Windows, и из-за этого в коде накопилось много хлама. После того как Алексей Брагин и другие разработчики изменили часть программного кода Arwinss, относящуюся к ReactOS, чтобы поддержать эти изменения, курсор мыши превратился в черный квадрат. Что ещё более любопытно, при перемещении курсора на границу окна, он превращается в правильный значок "изменения размера". В сотрудничестве с Яннисом Адамопулосом (Giannis Adamopoulos), Алексей получил подтверждение, что эта проблема находилась на стороне Wine и была связана с тем, что все точечные изображения курсора уже были выбраны в отдельном контексте устройства. Эта ошибка привела к невозможности дублирования всех точечных изображений курсора за исключением курсора изменения размеров окна. Алексей также обратил внимание, что программисты Wine уже решили подобную проблему в другой части их кодовой базы, таким образом он применил те же самые изменения к функции GetIconInfo, однако всё равно ему нужно предоставить патч с исправлениями в проект Wine. Помимо этого, данный случай продолжает оставаться проблемным, так как Алексей до сих пор не уверен, что другой контекст устройства не привязан к изображению курсора, что может быть причиной утечки ресурсов.

Две другие разработки стали частью усилий по исправлению ограниченной поддержки оболочки в Wine. Большинство людей, использующих Wine, редко нуждаются в ней, поскольку у них уже имеется отдельная запущенная оболочка, и лишь часть приложений, представляющих интерес для них, всё равно используют функциональные возможности оболочки. В транке фактически уже есть все эти функциональные возможности, но, как было сказано выше, их поддержка никогда не была приоритетной для проекта Wine. Одной из проблем была нехватка обработчиков в оболочке, которая была наиболее заметна в том, что запущенные приложения не отображаются в панели задач. Этого стоило ожидать, так что исправление этой ошибки считалось приоритетной задачей. Текущая оболочка ReactOS Explorer также должна была иметь дело с этими недостающими функциональными возможностями в прошлом и фактически имела хаки в тех местах, где мог происходить опрос выполняющихся процессов, с целью узнать, какие из них имеют видимые окна, добавляя их и удаляя при закрытии. Правильно это делается при помощи оповещений от обработчиков в оболочке при запуске и закрытии приложения. Маартен Крёзе (Maarten Kroese), который формально ещё не является разработчиком, но уже близок к этому, был занят реализацией этих обработчиков для Wine, и намеревается отправить им патч, который, в конечном счете, окажется также и в Arwinss.

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

Старый новичок

Амин Хальди (Amine Khaldi) — опытный участник нашей команды, он довольно долгое время поддерживал Bugzilla, дёргая разработчиков по поводу томящихся в ней ошибок и патчей. Недавно он стал полноправным разработчиком, работая над заголовками ReactOS, и мы ожидаем, что он будет заниматься подобной работой в течение достаточно долгого времени. С другой стороны, Жером Гардо (Jérôme Gardou), ставший недавним пополнением команды, уже добился больших успехов в yarotows, ветви ReactOS. Более подробное разъяснение того, чем же всё-таки является yarotows, будет дано позже, а пока упрощенно можно сказать, что это ещё одна попытка привести подсистему Win32 в порядок, и прогресс достиг точки, когда слияние частей этой ветви в транк приносит заметную выгоду.