ROS Newsletter78

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

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

Стек звука

Стек звука в Windows имеет довольно четкую структуру, но рассказ о нём, который вы могли прочитать в выпуске новостей №65, был очень кратким и, вероятно, запутанным, поэтому далее представлено более подробное описание. В звуковой карте вашего компьютера имеется два типа сигнальных линий: входные и выходные. Входные линии предназначены для ввода аналоговых сигналов от различных источников, например от CD-ROM, микрофона и тому подобных устройств. Выходные линии предназначены для вывода сигнала со звуковой карты на громкоговорители, наушники, и т.п. Они могут быть связаны между собой в единую микшерную "линию" от источника до устройства воспроизведения звука, однако возможен только один путь от любого из источников сигнала к любому из выходов.

Линии представляют собой топологию, включающую в себя входы, выходы, а также связывающие их между собой компоненты. Конечные точки топологии в модуле потоков ядра (kernel streaming module) называются пинами. Входные пины являются конечными точками линии-источника, а выходные пины являются конечными точками выходной линии. Помимо пинов, существуют компоненты, называемые узлами топологии. В то время, как пины представляют собой источник сигнала или выход отдельной микшерной линии, узлами топологии являются сами микшеры, формирующие линию. Эти компоненты управляют, например, громкостью и тональностью звука, а также позволяют включать и заглушать звук. Также существуют заполнители узлов, представляющие собой разрывы цепи узлов и, технически, микшерной линии более не нужны никакие микшерные узлы. Это во многом сродни начальным этапам разработки звука в ReactOS, где было невозможно контролировать уровень громкости.

Микшерные линии, состоящие из пинов и узловых цепей, должны быть правильным образом настроены, кроме того, их состояние необходимо постоянно отслеживать, поскольку при смешивании линий возможно возникновение странных побочных эффектов. Недавно проведённая Йоханнесом Андервальдом (Johannes Anderwald) работа заключалась в тщательной проверке того, какие компоненты должна иметь линия и распределению узлов по своим линиям. Также, в код были добавлены проверки цепей, в которых узлы по какой-либо причине соединены между собой. Всё это вместе должно увеличить количество работоспособных мультимедийных приложений и уменьшить количество случаев появления странных шумов при воспроизведении звука или даже его полного отсутствия.

Системные сообщения мыши

Код ReactOS, предназначенный для обработки данных, принимаемых от мыши, получает эти данные от драйвера и преобразовывает их для последующей передачи процессам в виде системных сообщений Windows. Однако существующая реализация этого кода крайне устарела. Похоже, что он присутствует в ReactOS ещё со времён использования нами CVS, и с тех пор ничуть не изменился. К тому же, его структура была неправильна, и, во многих отношениях, противоречила структуре своего аналога в Windows. В Windows существует поток, который называется потоком необработанного ввода (Raw Input Thread или RIT), который принимает данные от клавиатуры и мыши. После того, как RIT принял эти данные, он проверяет список открытых окон для того, чтобы определить, какому из приложений необходимо получить эти данные. Затем RIT преобразует принятые данные в соответствующие системные сообщения Windows и добавляет их в конец внутренней очереди сообщений приложения. Приложения, которым необходимо прочитать системное сообщение, могут сделать это при помощи функции PeekMessage, один из параметров которой определяет, необходимо ли после обработки удалить это сообщение из очереди.

С другой стороны, в ReactOS имеется два потока, по одному для клавиатуры и мыши. Более того, поток мыши не отправляет сообщения в очереди сообщений приложений, а добавляет их в общесистемную очередь сообщений. Поэтому вызов приложением функции PeekMessage приводит к проверке общесистемной очереди сообщений, а не очереди сообщений конкретного приложения. Это может привести к непредсказуемым результатам, так как приложения могут прочитать системные приложения Windows, не предназначенные для них.

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

Яннис Адамопулос (Giannis Adamopoulos) работал над устранением описанных выше проблем, и первым, что он решил сделать, стало получение потока данных мыши и отправка его к очередям сообщений приложения, а не в общесистемную очередь. Это также требует исправления функции PeekMessage, чтобы она могла использовать очередь сообщений приложения, поэтому Яннис импортировал в ReactOS часть кода Wine, отвечающую за некоторые дополнительные функции преобразования сообщений. Помимо того, возникло несколько других проблем, например, были обнаружены ошибки в коде функции WindowFromPoint, которая извлекает дескриптор окна, находящегося в заданной позиции на экране, вследствие чего программный код этой функции пришлось переписать заново. Заключительным этапом станет слияние двух потоков в один, позволяющий производить обработку данных с клавиатуры и мыши, но это будет сделано чуть позже, поскольку новый код потока данных мыши необходимо тщательно протестировать.