ReactOS News Bulletin No. 83

Memory Usage in GDI

In the process of rewriting the graphics device interface support manager (GDI), Timo Kreuzer was confronted with what can only be called a monstrous waste of memory. The amount of allocated memory for created objects was always a full page, i.e. 4 Kb, regardless of whether the object needs such a large amount of memory to store its attributes. This results in significant wasted memory, as well as wasted memory addresses. Timo suggests that this is one of the reasons leading to a leak in the task manager of many memory pages at a time. Win32k has a caching mechanism for such allocations, which, apparently, does not reuse freed pages, therefore, within a certain amount of time, all the system memory may be exhausted.

Fortunately, Timo managed to solve these problems. He developed memory pools for each type of attribute of an object for each process. Whenever an object is created or destroyed, memory is allocated or deallocated in these pools. Pools are organized into sections, the size of which varies from one page in 4 Kb and up to 64 Kb. Each pool begins with one section, if necessary, a larger number can be added, however, the total amount of memory allocated at each object creation does not exceed the actual amount required for each attribute. A bitmap is used to designate the free memory segments of each pool, and the search for memory available for distribution is much faster than before when the method of paging each attribute of the object was used to create it.

In addition to speeding up and getting rid of wasted memory, pools also eliminate the need for an old caching mechanism. Pools themselves act as a kind of cache, containing a reserve of memory that is quickly available for use during the creation of an object. Thus, Win32k does not need any additional mechanisms designed to process old memory blocks and prepare them for reuse for new objects.

New USB driver

Johannes Anderwald has worked on a wide range of ReactOS components, from the kernel to Win32k and sound support, and now he is busy developing USB. Expressing interest in introducing USB support, he suggested that Michael Martin rewrite USB drivers from C to C ++ to make them easier to read and support. Michael agreed and completely focused all his activities on the new EHCI driver. Their current goal is to refine this driver to such a state that its functionality is comparable to that of the old EHCI driver written by Michael. It was decided to abandon the development of the old driver before proceeding with the development of the usbhub driver, which is responsible for sending I / O request packets to the EHCI driver.

Projects accepted in Summer of Code

The ReactOS project was allocated a limit of six vacancies under the Google Summer of Code, and all information about the selected projects was posted here . For personal reasons, I did not have enough time for a more detailed coverage of the essence of these projects.

TCP / IP Driver

There have already been many attempts to implement a high-quality implementation of the TCP / IP protocol in the ReactOS network stack. The latter was to use the oskit library to support TCP / UDP, but its integration, as it turned out, is a very, very complicated process. In any third-party library we use, for us in the first place is the possibility of easy updating when a new version is released by another project. If the code requires close integration with the system, the task is much more complicated. The lwIP library is intended primarily for use in embedded systems, making them very lightweight and self-contained. We hope that we can integrate it correctly into the ReactOS network stack.

Explorer_new

Work on the new shell began a few years ago by Thomas Bluemel and was continued by Andrew Hill. Most of the missing functionality is the result of an incomplete implementation of the shell32 library, mainly the accuracy of explorer_new depends on its readiness. So working on explorer_new also means working on the Shell32 library. For this project there are already a large number of developments, but to complete it will require a lot of effort.

Theme Support

Support for themes is one of the most popular features in ReactOS, although most often only users who think that a beautiful user interface will attract more people to the project ask for it. It also refers to the poorly documented components of Windows, which makes it difficult to properly implement it. Nevertheless, Giannis Adamopoulos has conducted research in this direction and believes that he can deal with the implementation of this component.

Audio Mixing

Although Johannes Anderwald and achieved some success in working on the ReactOS sound stack, nevertheless, much more needs to be done to develop support for the simultaneous management of multiple audio streams. This is an extremely necessary functionality, especially if the user is enabled for sound notification of events occurring in the OS or applications. ReactOS currently supports these features very poorly, so having an audio mixer would help make the system much more usable.

Kernel mode test suite

This is what Amine Khaldi has been striving for since the set of tests directly interacting with the kernel functions could significantly speed up and facilitate the search for problems that lead to crashes when ReactOS boots or disrupts the normal functioning of the system. It is also interesting to see how they will be implemented, because if the test fails, the probability of a critical failure in the OS is high.

GDI Font Driver

A couple of years ago, in one of the news releases, I described in some detail the problems associated with rendering fonts in ReactOS. If you are interested in the details, then you can familiarize yourself with them here. In short, the rendering method in ReactOS turned out to be completely wrong and we ignore most of the information provided by the glyphs of the font. A correct font driver could solve this problem and save us another big flaw in the Win32 subsystem architecture.

Another developer

Gabriel Ilardi received commit access some time ago, but since he was absent from the IRC channel for several weeks, this fact jumped out of my head when I wrote the previous news release. In any case, please welcome another developer who has joined our ranks.

Translated by: evilslon , Farwalker , serrox