ReactOS Newsletter: Newsletter 70

Author: Z98. Link to original: (English).
Tags: FOSS, Newsletter, ReactOS, windows Submitted by evilslon 31.03.2010. Public material.
Перевод на русский язык выпуска новостей ReactOS №70

Translations of this material:

into Russian: Выпуск новостей ReactOS №70. Translation complete.
Submitted for translation by evilslon 31.03.2010 Published 8 years, 6 months ago.


UniATA Timing

UniATA continues to be problematic, with testers often struggling to get past the first stage install much less actually put ReactOS through its paces. As mentioned before, the time UniATA waits for responses from hardware is considerably lower than that of the old ATA driver. On older hardware, sometimes various drives are not fast enough in responding so operations time out and UniATA reports an error even when there technically was nothing wrong. The first attempt to resolve this was to change the wait times to that used by the old driver, but a few developers expressed dissatisfaction with this. Since then, Olaf Siejka has led an effort to try and find a compromise time that would not result in time outs on the majority of hardware and also identify where exactly these timeouts are occuring. This has not been a trivial task and Olaf's patience is commendable.

One of the major issues UniATA has been causing is dropping the boot drive. This could be either the CD drive or the hard drive, but either way it effectively killed ReactOS as the drive with the operating system was now gone. Olaf was not the only one to run into this, as both Daniel Reimer and Gabriel ran into the same problem, albeit under differing circumstances. Daniel was preparing for the Chemnitz expo and was setting up his laptop as a demonstrator, but could not get UniATA to function on it. Gabriel was testing ReactOS on VirtualBox but had his CD drive set as a slave on his primary channel. Aleksey Bragin managed to fix Gabriel's issue, but Olaf and Daniel were both still stuck. Interestingly when Olaf switched UniATA to full debug mode the problem disappeared, which is highly suggestive of a timing issue. After what can only be described as a mind numbing procedure of manually adding and removing debug print statements in every UniATA function, Olaf managed to narrow the issue down to three that were responsible for interrupt handling. However, this ultimately turned out not to be quite as definitive as if debugging is silenced in just those three functions, the problem still does not occur. Thus the issue could be far more pervasive than just those three functions and more extensive testing will be necessary before any conclusions can be made. At the same time, the Arm team and Timo Kreuzer have been busy rewriting the trap handling code which may have resulted in other changes to the timing of interrupt handling. Thus the actual cause of the problem may be somewhere further down the stack.

PnP and ACPI

Plug and Play is the system that allows an operating system to detect when new hardware has been installed or connected. When one decides to add perhaps a new graphics card, the OS becomes aware of the change through PnP. Otherwise the process of detecting the new change is left to the user to manually initiate, a not too pleasant task. PnP in ReactOS was incomplete in many ways and various parts were hacked to compensate for missing components. One thing missing was Freeloader, the ReactOS bootloader, reporting the various devices it detects to the PnP Manager. As a result, the operating system would not know to initialize the drivers it has for them or ask for drivers if it does not have them. Cameron Gutman recently added the necessary code and ended up making a few other fixes related to device descriptions that the PnP Manager also maintains.

In the process of this, Cameron ran across a bug in which the computer was also identified as not supporting ACPI. The Advanced Configuration and Power Interface is used for power and device management on systems that support it. ReactOS support for it ranged from tenuous to nonexistent, depending on the layer of the operating system one is looking at. One problem was the PnP Manager was not handling all of the devices the bootloader was reporting to it. Freeloader, the ReactOS bootloader, passes a list of devices it detects through the registry and the PnP Manager is supposed to read this and create additional registry entries for all the devices. Converting between the two requires the PnP have the correct IDs and this data must be hardcoded in the code. Unfortunately the PnP Manager was missing a few IDs so some devices did not get an entry in the registry. As a result, the operating system would not know to initialize the drivers it has for them or ask for drivers if it does not have them. Cameron Gutman recently added the necessary IDs and ended up making a few other fixes related to device descriptions that the PnP Manager also maintains. A side problem was the registry key for the ACPI driver was marked with the volatile flag, resulting in the ACPI driver being reinstalled after every reboot. Cameron has fixed this but his recent work seems to have tripped over some very old cruft in the lower levels of the operating system. Right now many people are experiencing problems with the mouse in the second stage of the installation and when the OS first boots to the desktop and the ARM team currently recommends that ACPI remains disabled until more work is done in the Hardware Abstraction Layer to more fully support ACPI.


The Digital Video Broadcasting-Terrestrial standard is one of the broadcast standards for digital television. It is used in Europe, Russia, Greenland, Australia, parts of Africa, south Asia, and a few other parts of the world. Computers with digital TV tuners can stream shows but of course the operating system must support decoding the broadcast stream as well. Johannes Anderwald decided to take a small break from sound development while he waits for more detailed bug reports and has been working to add support for DVB-T to ReactOS. This required a software stack extending from user mode down into the kernel. The required kernel components are ks.sys, which people should recognize as the kernel streaming component that general sound support required, and bdasup.sys, a support driver for various broadcast devices like TV tuners. The usermode side consists of several DirectShow filters and capture components such as msdvbnp and ksproxy as well as bdaplgin, a ksproxy used to communicate with the kernel components. These filters are the ones that determine the channel the kernel should tune into and then receives and forwards the audio/video stream from kernel mode. The user of course still needs an application to do the decoding of that stream to play it, though finding one is not that difficult. Johannes has been mostly testing his user mode code on Windows XP, replacing the COM registrations to hook his stack in place of the original one included with Windows. When he moves onto testing the kernel components, Johannes is likely to plug the original DirectShow filters to reduce the possible points of failure. While complete support is still a whiles of, Johannes has achieved quite a bit in a short amount of time. Those who want him to apply that same speed to the sound work will need to help motivate him by providing more detailed bug and debug reports.

© ReactOS Team. License: FDL