ReactOS Newsletter: Newsletter 97

Author: Z98. Link to original: (English).
Tags: FOSS, GPL, Newsletter, ReactOS Submitted by evilslon 08.08.2013. Public material.
Newsletter 99 by Z98 on 2013-09-09 - Shell - Emergency Management Services - SVCHOST - CreateProcess - Windows DLL Loading

Translations of this material:

into Russian: Выпуск новостей ReactOS № 98. Translated in draft, editing and proof-reading required. Completed: 99%.
Submitted for translation by evilslon 08.08.2013


Explorer Shell

A while back the project announced a development contract for Giannis Adamopoulos to work on getting the necessary supports for running explorer-new to run on ReactOS. Since then, Giannis has been very busy and has made considerable progress. Much of his work has been properly separating responsibilities in the various components so that there are clear delineations of who does what.

There are two major accomplishments, both fairly wide in scope. The first involved breaking out context menu handling from code that handled displaying content. Previously all of this was mixed together and created major problems trying to understand and work with the code. Giannis has managed to separate responsibility into two separate components the way it should be, which will likely help the sanity of whomever else has need to step into the code into the future.

The other major accomplishment is the fleshing out of three shell classes, IShellBrowser, IShellView, and IShellFolder. These three work together to produce the view of the desktop and explorer that most people are familiar with. IShellBrowser and its descendants are responsible for the windows people see including the menus and toolbars, IShellView handles showing files and folders as files and folders that a user can click on, and IShellFolder lets IShellView know what folders and files to display. The interactions between the three are fortunately fairly well documented for the most part so Giannis knows how things should be done.

Because of ReactOS' lack of a decent implementation of the above three shell classes, the current explorer shell actually has its own in-house implementation. In addition, missing functionality forced the current explorer to use a variety of hacks to accomplish things as simple as opening a folder. The experience with the current shell has actually steadily worsened over the years simply because the hacks have slowly unraveled with more and more pieces being implemented properly. This makes Giannis' work very important from a usability perspective.

A lot of work remains however and one big piece is dealing with the start menu. The classes related to it are undocumented and Giannis and Thomas Faber have been doing some research to try to understand how the start menu is put together. Another piece is the rebar, the bar that hosts toolbars and allows users to move them about. Those two pieces combined with Giannis' other work should theoretically be enough to allow for a basic new explorer shell to be dropped in.

As a final note, Giannis was able to take advantage of a large amount of code written by Andrew Hill, a former ReactOS developer that had made a first pass at implementing a proper shell32. Though Andrew is no longer part of the project, his work has proven invaluable and he has the project's thanks for the effort he gave. Another person whose code Giannis referenced was Colin Finck, someone who needs to get back to the project so that I can stop being solely responsible for being the release engineer. Colin's work was originally intended as an attempt at implementing the Microsoft Management Console but Giannis found it very useful as a starting point for the toolbar component.

Mapping Control Block

In order for ReactOS to support more advanced filesystems, the infrastructure supporting filesystems needs to be more complete. One of the needed Filesystem Runtime Library subsets involves the mapping control block which handles mapping between virtual and logical blocks. Simplistically, logical blocks are how storage units are organized on a disk whereas virtual blocks are an abstraction an operating system is often presented with. Aleksey Bragin developed an implementation while Pierre Schweitzer provided a test suite for that implementation. Aleksey ran the tests against Windows 2003 to observe their behavior and based his work on that. So far Aleksey's implementation mostly passes, except for a few corner cases such as the merging of virtual blocks in situations of continuous logical blocks. Once those cases are dealt with, one more piece of the filesystem stack will be complete.

More Build Improvements

Not satisfied with the already improved build time he achieved with the ninja conversion, Amine Khaldi went and coordinated four more changes to the way ReactOS is built. The first major improvement came with significantly reducing the amount of debug information generated for use with rossym. Previously rossym was reliant on the stabs format of debug information, which did not have very fine grained control over the verbosity of that data. Art Yerkes leveraged Wine's dbghelp code to get rossym to support DWARF debug information, which allowed Amine to configure the build to generate only the absolute minimum needed by rossym. Another tweak was being smarter about how to build ISOs. Amine examined the way in which the ISOs were laid out and provided some guidelines to Art. Art then modified cdmake, the utility the project uses, to be able to accept a map file to define the ISO's layout instead of needing to create a directory and duplicating built binaries in it.

The other two changes were centered around trying to decrease build time. One change was to use a slightly less efficient compression option when creating cab files, which while reduced compression time by 50% only increased the resulting size of the archives by about 65kB. The last change was to change the optimization level used in compiling ReactOS to O1 instead of Os. Os optimizes for size while also trying to achieve the performance optimizations of an O2 level optimization run, whereas O1 is nowhere as aggressive from an optimization perspective. Based on some research Amine did, he found that O1 does not suffer any performance penalties compared to Os but is faster due to its less aggressive optimization phase. The culmination of all this saw the size of the output from a compilation of ReactOS be reduced from approximately 4GB to around 500MB. Not only does this save considerable amounts of disk space, the reduced size also means less I/O during the build process and the ability to basically cache the entire build in memory, which speeds things up even more, which also means more memory is available for either multiple simultaneous builds or other work on the project's build servers. This is a considerable achievement that has won Amine and Art the gratitude of all of the developers that have had to sit through a build or have multiple checkouts.