ReactOS Newsletter: Newsletter 50

ReactOS Newsletter - Newsletter 50 (#50)

The Perils of PSEH2
MSVCRT
Win32k Init
Development Methodology

Newsletter Archive

by Z98 on 2008-12-20

top

The Perils of PSEH2

While KJK did get PSEH2 out in record time, this meant that it was relatively untested when he committed it and developers began using it. Currently PSEH seems to be corrupting data when exceptions get thrown, which then cascades down and causes functions to assert and crash, something that it was supposed to prevent. Michael Martin's theory about what is happening is that PSEH is clobbering local variables that are being held in registers, though KJK attributes it to an issue of not using setjmp. The rest of the details are, in his words, "complicated." KJK has committed fixes for the variable corruption problem, but he expects more problems to show up. On the other hand, this spat of issues has prompted KJK to begin writing a test suite for SEH. He has about 70 tests so far and will commit it to trunk soon, with more following.

One of the more serious issues that cropped up was when ReactOS gets to the login, the system actually had not loaded the components for reading input from the keyboard. This predictably resulted in not being able to get past the login and a great deal of frustration on the part of testers. Unfortunately, even with KJK's most recent fixes, the issue has still not been fully resolved.

top

MSVCRT

The MS Visual C++ Runtime library provides most of the basic services a C++ program may require, though MSVCRT technically is only for programs developed using Visual C++ versions 4.2 through 6 and certain internal components. Newer programs are not supposed to link directly to it, though for the sake of backwards compatibility the Windows SDK still allows you to do it. Interestingly, it was the poor handling of MSVCRT in the 9x family that contributed to most of the DLL hell that people experienced. ReactOS also has its own copy of MSVCRT, though it was cobbled together from a variety of sources in order to provide the various functionalities needed. This created a a lot of problems that Gregor Schneider has been working through to get the ROS MSVCRT to pass more Winetests. He's made good progress, with the unit tests for dir, cpp, printf, and string basically done. Most of the work involved eliminating duplicate or incorrect code and updating to Wine's versions now that their implementation has matured.

top

Win32k Init

One annoying side effect of fixing one issue in ReactOS is that you might expose an underlying bug, which would explain why the hack you just fixed existed in the first place. Jim Tabor stumbled upon this very situation when he fixed a problem in GDI32 only to run into a very nasty bug in the initialization of the Win32k subsystem. Since so many things depend on Win32k, any failure in its initialization pretty much renders the system unusable. The root of the problem is that the components are not being initialized in the correct sequence. This led to developers creating interdependencies across various components and it's now coming back to bite us. Case in point, CSRSS attempted to use a function called ExtractIconExW, which is located in shell32.dll. The problem is that shell32.dll requires a valid user account when it initializes, whereas CSRSS handles matters such as the console and threading, which are needed almost immediately after booting. Thus when CSRSS is started, the user hasn't even had a chance to log in yet. Eric Kohl worked out that particular issue, but Jim's certain there are more lurking around.

top

Development Methodology

As I have often said, the memory manager is probably the weakest component of the kernel right now. It is one of the last chunks of code left over from before Alex Ionescu's kernel rewrite. There is a great desire to get it fixed while avoiding a complete rewrite, which would be a really long term goal but just not practical to attempt right now. Also take into consideration the fact that the common cache relies in the memory manager and file systems rely on the common cache and you have even more reason for wanting the memory manager in better shape.

Instead of a bottom up approach, which one would take in order to do a rewrite, Aleksey Bragin has opted to take a top down approach to fixing the memory manager. To do this would require fixing the issues in the filesystem drivers we do have, specifically fastfat and CDFS. Both were developed against ReactOS and then tested on NT, which resulted in some issues cropping up. Instead, Aleksey wants to develop on NT and then test the drivers on ReactOS, which is likely to expose all kinds of issues in the memory manager, common cache, and probably the FsRtl implementations as well. As with all approaches, there is a catch. People who know how to write Windows IFS drivers well and don't work for Microsoft number probably in the dozens, if even that many. How quickly Aleksey himself can rewrite the FS drivers, time will tell.

top