Community > ReactOS Newsletter Archive > ReactOS Newsletter: Newsletter 62

Newsletter 62

by Z98 on 2009-07-21

PSEH Corruption

In NT operating systems, structured exception handling is used to help safeguard probing of user mode memory buffers and pageable memory while in kernel mode. This requirement was what motivated the creation of the PSEH library by KJK::Hyperion since GCC does not have support for it. Since the last attempt to add SEH support to GCC failed, ReactOS remains dependent on PSEH. Recently, the ARM team committed some code which exposed a very nasty bug in the PSEH library and investigation of the issue led KJK to discover another bug while analyzing the code. Both were fairly serious, as they ended up causing major problems when exceptions were thrown.

The first bug involved nested try/catch blocks, wherein if an exception was raised and caught in the inner block and another exception was raised in the outer block, the code would jump not to the outer block's catch statement but the inner block. Execution would then progress from the inner block again and result in an infinite loop as the code constantly jumps back. What was effectively happening was that the trylevel for the inner block was not being popped when the code left the block and were left on the stack, which made PSEH think it was still in the inner block. This of course rendered the OS unusable when the bug was triggered, which was what happened after the ARM commit and a test in the automated testing combined to trigger it. With some help from Stefan Ginsberg, KJK managed to find the cause of the bug in the nested try/catch blocks and automated testing is now working again.

The second bug is somewhat similar to the first one, in that the execution frame of the exception was not removed from the stack, which would have a completely random result. The really bad thing about this was that this bug could be triggered without nested try/catch blocks so that even while it did not stall the OS, it essentially resulted in random stack corruption which could affect other things and eventually cause hard to trace corruptions. Since this was happening every time an exception was raised in SEH,
it would not be surprising if it was the cause of many random crashes ReactOS has suffered since the introduction of PSEH2. Ironically, an identical problem also existed in PSEH1 and also had the same fix. KJK's PSEH test suite also helped, once he added a sanity check that was missing. Of course, adding that check resulted in his code failing the majority of the tests until he fixed the bug.

XLATEOBJ

The XLATEOBJ is a data structure with a few associated functions that helps translate colors between different surfaces, such as from a bitmap to the color format of a display. Since this operation happens all the time it is important that it be fast. The ReactOS implementation unfortunately was not, with one of its functions using a series of if/else statements to decide how to do the translations. Timo Kreuzer replaced this with callback functions that only do what is needed, with a few optimized functions for special formats. Another change Timo intends to make is instead of dynamically allocating a XLATEOBJ from the paged pool every time a bitblt operation takes place, it is now allocated from the stack.

Normally a pixel by pixel translation is done when translating between the color formats. As its name suggests, when using a pattern brush a small pattern is used that gets applied to the target surface. Before the brush is used, a call is made to the driver by GDI through the DrvRealizeBrush function to translate the brush pattern to the target surface color format. This is called realization. At the same time, GDI can create its own brush realization should the driver report that the card does not support the function. ReactOS did not previously do this but Timo has made the modifications in his working copy and after making sure he did not breakanything will be committing it.

Arwinss

Aleksey Bragin recently created a new branch called Arwinss, which seems to represent another rewrite of the Win32 subsystem in one fashion or another. He also sent out an email detailing why he created it and why he took this particular approach. The reasoning boils down to Aleksey's frustration with the current Win32 subsystem and its many bugs. While several other developers have worked long and hard trying to get the system working, there are still major, long standing bugs in it. Many of these are due to hacks and incorrect implementations from the past and fixing them is essentially rewriting the subsystem anyway. Aleksey thus decided to take things a step further by reimplementing basically everything.

There is a substantial amount of Wine code in the branch, imported from the latest Wine release. The difference this time however is Wine's architecture was left intact. The hierarchy of calls in Windows can be surprisingly complex, much of which is not duplicated in Wine. Aleksey chose to continue this simplification and condense the layers. He created a significantly smaller win32k component for the kernel side of the subsystem, again borrowing some Wine code to make interfacing with the Wine user mode DLLs easier but adding his own modifications to make the entire thing work on a NT OS. These changes are likely to be the most controversial. Currently that simply means using the branch, in Kamil Hornicek's words, feels like using ROS 0.1.0. Text display is completely misaligned and mashed together and a color translation issue results in the expected blue title bars to turn brown. This is expected to improve as more pieces fall into place, but functionality will pretty much be crippled until then.

A few developers have commented on Aleksey's work and not all are supportive of this approach. Timo Kreuzer has pointed out that in the long term, this has the risk of hurting the effort to properly implement the Win32 subsystem. Timo is one of the developers that advocate a proper implementation that fully duplicates not just the Win32 interface but also the design of the subsystem itself along with its associated layers. While this might seem like a great deal of unnecessary work initially, Timo believes that it will result in a far more compliant system than Wine could ever achieve because of the shortcuts Wine takes.

Aleksey's little project is likely to cause some turmoil, at least until it can be reconciled with the concerns other developers may raise. At the same time, it does offer the possibility of a clean start so that an implementation is done correctly from the start without hacks. Only time will tell whether this ends up working or not.