Доступен перевод 93 выпуска (http://www.reactos.org/ru/newsletter_93.html) новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003).
Окна и Рабочие столы
В операционных системах семейства Windows рабочий стол, который видит пользователь после окончания загрузки компьютера, состоит из трёх составных частей: объект режима ядра, окно пользовательского режима, и поток. В объекте "Desktop" нет ничего особенного, а вот окно и поток представляют куда больший интерес. В Windows, окна рабочего стола создаются несколько иначе, чем обычные окна, и используют единый поток обработки данных. Этот поток обрабатывает системные сообщения, отправленные окну рабочего стола даже в том случае, если оболочка проводника не запущена и пользователи видят лишь пустое окно рабочего стола.
В ReactOS, окна рабочего стола обрабатываются как обычные окна и имеют свои собственные потоки, что приводит к довольно неприятным последствиям. При этом необходимо, чтобы каждый поток ссылался обратно на объект рабочего стола, что приводит к его дублированию и подключению к потоку функцией, которая занимается фактическим созданием рабочего стола. Всё это приводит к созданию большого числа разрозненных копий дескрипторов и ссылок на объект рабочего стола, кроме того, в настоящий момент в системе нет механизма для обнаружения и освобождения дескрипторов и ссылок при уничтожении объекта.
Также, в ReactOS существует ещё одна, куда более серьёзная, проблема с обработкой создания рабочего стола. При создании окна, из нераспределённой памяти текущего рабочего стола выделяется часть памяти для хранения структуры WND, предназначенной для приёма системных сообщений для этого окна. При создании уже существующим окном нового окна рабочего стола, память для структуры WND выделяется из кучи старого окна, а не нового. Если старый объект рабочего стола уничтожается, его куча также изымается диспетчером памяти и впоследствии может быть использована повторно для каких-либо других целей. Однако новый объект рабочего стола всё ещё существует и при приёме сообщений полагается на существование структуры WND, находящейся в этом участке памяти. Это может вызвать повреждение памяти и сбой в работе нового рабочего стола со всеми вытекающими отсюда неприятными последствиями.
Яннис Адамопулос (Giannis Adamopoulos) потратил немало времени переписывая NtUserCreateDesktop, чтобы исправить все описанные выше проблемы. Самым крупным изменением стало объединение всех потоков рабочего стола в единый поток, который избавлял от необходимости многократного дублирования дескрипторов и ссылок на окна рабочего стола для передачи их соответствующим потокам. В теории, он мог бы создать механизм уничтожения потоков рабочего стола для удаления ненужных дескрипторов и ссылок и в старом коде, но объединение всех потоков рабочего стола в один поток устраняет саму необходимость дублирования дескрипторов и ссылок.
Теперь единый поток рабочего стола не никому не принадлежит, а в систему был добавлен механизм, по необходимости выдающий временный доступ к дескрипторам и ссылкам объектов рабочего стола. Кроме того, Яннис также добавил в код специальную проверку создания окна рабочего стола, предназначенную для контроля за тем, чтобы все выделения памяти для нового она рабочего стола происходили из новой кучи рабочего стола, тем самым устранив возможное повреждение памяти, о котором говорилось выше. Это исправление, к сожалению, пока не используется в ReactOS из-за проблемы, связанной с поддержкой курсоров в окнах рабочего стола.
Так получилось, что необходимые данные о курсорах находятся в библиотеке user32, а код, отвечающий за обработку сообщений курсора находится в библиотеке win32k. Как только Яннис разберётся в том, как получить необходимую ему информацию, в ReactOS будет устранена ещё одна крупная архитектурная проблема.
Многим было бы интересно, зачем вообще нужно было связываться с этими очистками, ведь создание и уничтожение окна рабочего стола явно далеко не самое частое и обычное явление. В качестве одного из ответов на этот вопрос можно сказать, что ошибки такого рода приводят к утечке ресурсов, и хорошей практикой при программировании является устранение таких проблем, поскольку в непредусмотренной ситуации они могут привести к большим сложностям при отладке. Другим ответом может быть тот факт, что некоторые приложения в целях обеспечения безопасности используют несколько объектов "Window Station", и, следовательно, окон рабочего стола.
Для любопытных можно пояснить, что оболочка, которую пользователи видят в Windows, прежде всего состоит из сеансов, содержащих объекты "Window Station", в которых содержатся рабочие столы. Например, каждое соединение службы терминалов имеет свою собственную сессию, а в NT6 службы Windows выполняются в другом объекте "Window Station", чем рабочий стол пользователя. Это может оказаться полезным при создании изолированной от основной системы среды обработки данных (т.н. песочницы), и применяться в программах, которым необходимо защитить процесс от вмешательства простого пользователя и наоборот. Таким образом, создание и уничтожение окон рабочего стола является не такой уж и редкостью, как можно было бы предположить.
PSEH
Портируемая библиотека структурной обработки исключений (Portable Structured Exception Handling, PSEH) изначально была написана KJK::Hyperion, бывшим разработчиком проекта ReactOS, и предназначена для обеспечения структурной обработки исключений в компиляторах, созданных не в Microsoft. Для достижения этой цели, KJK пришлось пользоваться пользоваться недокуменитрованными функциями и особенностями поведения компилятора GCC, что, несомненно, является впечатляющим достижением, однако во многом зависит от прихотей разработчиков GCC, которые легко могут поменять в своём коде что-либо из того, что необходимо PSEH.
Тимо Кройцер (Timo Kreuzer) начал работу над новой версией PSEH, о завершении которой он объявил в прошлом месяце. Если вкратце, Тимо сделал различные изменения для обеспечения лучшей оптимизации и снижения сложности поддержки SEH. Прежде всего, пожалуй стоит объяснить, что собой представляют SEH и PSEH, чтобы облегчить понимание сути следующего абзаца. Обратите внимание на то, что последующий текст предполагает знания о том, какую роль имеют стеки в функциях программы, и общее понимание того, для чего необходимы исключения.
SEH - это функция уровня компилятора, поддерживаемая Microsoft, это означает, что её поддержка должна быть или встроена в компилятор, или же её реализация должна быть написана и размещена поверх него. Компилятор C++, созданный Microsoft, разумеется уже содержит в себе её поддержку, в то время как в GCC и Clang такая поддержка отсутствует. Разработка встроенной поддержки SEH в компиляторе представляет собой далеко не самую тривиальную работу, альтернативой этому является использование PSEH - довольно интересного хака, располагающегося поверх GCC. Поддержка SEH в коде программы обеспечивается посредством расширений языка программирования, в частности при использовании ключевых слов __try, __except, и __finally.
Те, кто знаком с обработкой исключений в C++, заметят отсутствие ключевого слова catch и добавление блока finally. Здесь ключевое слово __except выступает в роли эквивалента catch. Во многих аспектах это значительно усложняет функциональность __except, что, в свою очередь, может усложнить поддержку SEH. Ключевое слово __except позволяет программисту задать фильтр исключений, ответственный за принятие решения касаемо того, должен ли быть выполнен блок кода поддержки исключений, обёрнутый __except, или нет. В обычном C++, ключевое слово catch определяет единственное исключение, которое должно быть обработано соответствующим ему блоком.
В SEH, фильтр исключения может представлять собой свою собственную функцию. Дополнительным преимуществом является то, что любая функция, ука...
URL: http://www.reactos.org/ru/newsletter_93.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=35130
