As more components relating to filesystems sees implementation in ReactOS, they need to be tested. Pierre Schweitzer decided to try using Microsoft's FASTFAT driver to help in the effort, as using it successfully in ReactOS would indicate development is on the right track. Unfortunately, ReactOS' current common cache implementation effectively blocks that attempt due to its sorry state. The common cache has been touched upon in the past and mention was made of its problems. Art Yerkes recently did a code dump of a new implementation, but it currently does little beyond some setup and will need a lot more work before it can replace the current implementation. One interesting and rather surprising problem is how at least one of the functions in the current CC seems to be ignoring the length provided when it is asked to read something, instead just relying on filesize. Please note that filesize and length are distinct here, since one could ask to read a file but ask to read only part of it. For that matter, Microsoft's driver appears to be trying to read in a block of length zero, which is causing failures with the current CC.
So far Pierre has only managed to get the driver to succeed in initializing, which tests at least a very small portion of the FsRtl. Due to the state of the CC, Pierre began to experiment with Art's new implementation. While the driver does progress further in its operations, it still runs into problems due to bugs and missing functionality in the new CC. One problem appears to be not lowering the Interrupt Request Level before performing certain operations such as accessing paged memory. This issue however may not be caused by the new CC and could indicate deeper problems in the kernel.
Another issue discovered by Pierre and fixed with Aleksey Bragin was in the I/O manager. There are generally two types of I/O operations, synchronous and asynchronous. Synchronous operations result in the initiator of the operation waiting for the operation's completion. Asynchronous operations permit the intiator to go on doing other things and it is eventually notified of the operation's completion. I/O requests are described by I/O Request Packets (IRPs) and one can indicate whether a request is synchronous or asynchronous by setting specific flags in an IRP. However, if the IRP describes a paging I/O operation, the operation is going to be asynchronous unless the IRP_SYNCHRONOUS_PAGING_IO flag is set. There are other flags that one generally uses to indicate a synchronous operation, but all of those are ignored in a paging I/O operation. The I/O manager in ReactOS did not obey this convention and was incorrectly marking paging I/O operations as synchronous and returning the wrong status value. When Microsoft's FAT driver saw the incorrect value, it bailed out, leading Pierre to the problem.
ARWINSS Optimizations and Fixes
Because of ARWINSS' origins, there are certain characteristics in its implementation that may seem inefficient or redundant. One such instance is the duplication of handle tables in the kernel mode Win32k subsystem and the user mode Wine modules. To ensure proper interoperability, a mapping between the two tables must be maintained. Originally this map was implemented in the kernel side Win32k subsystem, but this would have required a costly mode switch any time a user mode component wanted to even read the map so Aleksey Bragin moved the mapping into the user mode winent driver. Because code in kernel mode can see anything in user mode, operations in user mode can defer a costly mode switch by writing data into a user mode location. This is still not quite ideal as having simply one table, but Giannis Adamopoulos has begun work on shared memory for ARWINSS which will eventually allow for it.
Top level window management was not something Wine really needed to worry about, as in a Unix environment X Window handles that. In ARWINSS, the Win32 subsystem has to deal with it but the entire situation is complicated by the shifting responsibilities. One has to keep in mind that in ReactOS a Win32 subsystem already exists with its own expectations, expectations that Wine does not meet. The consequence is problems with correctly drawing and clipping as Windows get moved around. Aleksey has fixed some issues and continues to work on others, but correctly calculating window visibility while dealing with two different types of behavior is tricky.
Colin Finck and Olaf Siejka have been busy working on upgrading the systems that build and test ReactOS. Currently ReactOS has underway an ARM and x64 port as well as a CMake transition and MSVC compatibility work. However, only trunk was being built and tested and automated building and testing of the other branches would be immensely useful. Olaf had already set up his own private build machine running on Windows and the last round of upgrades saw it added as a build slave to the team's collection of machines. A new user interface has also been set up to make it easier for developers and selected testers to request builds of specific revisions. Considering the power of some of the machines, having access to such systems will help speed up immensely regression testing and the like.
Pierre Schweitzer will be presenting ReactOS at his school, l'Institut Supérieur d'Informatique, de Modélisation et de leurs Applications (ISIMA), located in the city of Clermont-Ferrand, France, on Feburary 17 at 1:30PM local time. He will be accompanied by fellow Sylvain Petreolle and will be covering both technical aspects of ReactOS and some project history. If you have a chance, drop by and take a look.
Colin Finck, Timo Kreuzer, Matthias Kupfer, Daniel Reimer, and Christoph von Wittich, or basically the German contingent of the ReactOS team, will again be attending the Chemnitzer Linux-Tage in Chemnitz, Germany. They will be joined by Kai Tietz, a developer of the Mingw-w64 project with which ReactOS has been cooperating with on various compiler and development kit intiatives, so stop by and say hello.
Finally, community member Victor Martinez will be holding a talk on ReactOS IV Jornadas Tecnológicas de Isla Cristina taking place on March 31st to April 1st. The event will be at Isla Cristina-Huelva, Spain.
Driver Code Signing
A while back it was announced that the ReactOS Foundation had acquired a VeriSign code signing certificate, which allows us to sign drivers to run on 64bit Windows systems without having to jump through hoops and disabling a good deal of media components. The Foundation also announced that it was willing to sign drivers for other open source projects that may not be able to acquire a certificate. The conditions for signing have now been better formalized and are listed on this page. The main point is that the Foundation will not sign something that risks getting its certificate revoked, so nothing designed to circumvent OS security features or DRM will be signed by us. We will also generally ask that any issues highlighted by the driver verification tools be dealt with or at the very least explained. Otherwise, all that we require is that a project be under a free or open source license that a link back to the ReactOS Project be added to the site of the driver we sign.