ReactOS Newsletter №88

Author: z98. Link to original: (English).

Translations of this material:

into Russian: Выпуск новостей ReactOS № 88. Translated in draft, editing and proof-reading required.
Submitted for translation by dsp2003 12.10.2011


Newsletter 88


Another recent accomplishment by Claudiu Mihail, the Google Summer of Code responsible for transforming the lwIP library into a driver, was the completion and remerging of the shell32 library as C++ code instead of C code. The effort was started originally by Ged Murphy and Andrew Hill as C++ was better suited to implementing the COM aspects of the library. Ged had originally tried to do the conversion in trunk, but that proved too disruptive and he moved the code into a branch. Claudiu picked it up after finishing his GSoC project and cleaned up the code. Conversion of C code to C++ often results in some oversights like not assigning default values to class members in a constructor or updates to class members not being properly done. One of the bigger issues that needed fixing was control applets not starting up. The issue arose after Claudiu fixed the command line parser to pass Wine tests. The parser was correctly truncating the names of applets to their short form, such as "Add Hardware" to "Add," but an issue deeper in the shell code was not able to find the control applets using the truncated names. While this problem was fixed, other issues in ATL are preventing proper registration of shell extensions. Giannis Adamopoulos has also looked into the registration issues but so far have not been able to resolve it. Johannes Anderwald has also chipped in and stated that ATL may be the inappropriate mechanism to use for registering shell extensions. In the meantime Amine Khaldi has reverted the registration code to use the old Wine style registration mechanism, which while architecturally incorrect at least somewhat works.

As shell32 was never a major priority for Wine, its coverage by Wine's testsuite is not that extensive. That said, ReactOS still fails a significant number of the existing Wine shell32 tests. Claudiu is working on rectifying that and adding new tests to increase the coverage. With some cooperation from Victor Martinez, he has already added more tests for the command line parser, with tests for other areas hopefully on the way.

Loader Fixes

It has been a few months since Aleksey Bragin merged in his loader rewrite and the project has seen its fair share of regressions as a result. At least one regression however has been dealt with, relating to the use of something called security cookies. These cookies have nothing to do with internet sessions cookies, but with the calling of functions in order to catch memory corruption. Memory overruns and the like can happen on the stack as well as in the heap. For those who are not aware of the distinction between the stack and the heap, simplistically the stack is where all the local variables to a function are stored, whereas the heap is the source of dynamically allocated memory. When a function is called, the execution path is moved to another part of memory that stores the function's code. To return back to the caller so the program can continue after the function is finished, an address is needed. This address is stored as part of a function's stack and if a buffer overflow occurs on the stack, the address could be overwritten with gibberish. The cookie is placed before the address and changes to its value are what is used to signify some kind of corruption. If the address was corrupted, the operation that corrupted it must also have changed the value of the cookie.

The problem in ReactOS was derived from not initializing the security cookie correctly, as the cookies can come in differing sizes. If ReactOS used a larger cookie than the program desired, this can also cause the program to crash because setting the cookie may suddenly overwrite data on the stack because not enough space was provided for the cookie, leading to the same type of corruption and crashes that the cookies were meant to catch in the first place.

Debug Pool

A while back Aleksey completed implementation of the debug heap, a second heap designed to help track memory corruption when programs write outside the memory they had allocated. The debug heap is however a user mode tool, meaning it cannot be used to track down issues in kernel mode. Fortunately, Windows also has a debug pool that serves the same memory corruption hunting purpose for kernel mode. To that end, Aleksey has been working to implement the debug pool for ReactOS. As explained in a previous newsletter, the pool is from where memory allocations by kernel mode components are made. The debug pool works much like the debug heap, adding additional bookkeeping information to each allocation from the pool to check if any components writes over the memory it actually allocated. Since memory corruption in kernel mode is generally much more fatal, resulting in blue screens and the like, catching these and fixing the code that does this is of utmost priority.


Due to his experience with his other work, Pierre Schweitzer decided to try running the cppcheck static analysis tool on ReactOS source code to see what would turn up. The end result has been a steady stream of fixes for memory leaks across both ReactOS itself and the various tools and applications the project has developed, including the soon to be retired RBuild. Currently Pierre is not including the headers from the platform software, driver, and native development kits as that increases the scan time considerably.

The team has also been working hard putting together a new build environment that includes CMake in preparation for dropping RBuild. Originally the developers also intended to include GCC 4.6, but a problem in the way a variety of intrinsic functions are exported by the GCC toolchain prevented them from making the switch. ReactOS has the intrinsics and their exports in the kernel32 library, but GCC had them in their mingwex library. This resulted in the linker seeing duplicate exports for the same function, which caused linking of binaries to fail. The Windows build environment will also start using a MSI installer instead of NSIS, a long time goal of the Windows BE maintainer Daniel Reimer.

CMake builds have already been built for quite some time on the Windows build machines Olaf Siejka maintains and the team is now working on getting the Linux build machines to produce and test ReactOS.

Keyboard Input

Last year Giannis did some work on the handling of mouse input messages. This year, Rafał Harabień decided to take up the keyboard side of input handling. To identify which key was hit, keyboards send scan codes to the computer. These scan codes are then mapped to whatever keyboard layout is in use so the operating system and applications will know what letter or special virtual key the user wants to input. As with much of ReactOS, the code implementing support for keyboard input had its share of issues. ReactOS had actually hardcoded the values for several scan codes so regardless of which keyboard layout the user had selected, those keys would always result in the same interpreted input. This breaks compatibility with any keyboard layout scheme that does not match the hardcoded scan code values. Rafał has rewritten the code to correctly map to keyboard layouts and intends to continue Giannis' work of merging the mouse and keyboard input threads into a single raw input thread. He also intends to fix support for multiple keyboards and get ReactOS to pass more of the Winetests related to mouse and keyboard input.