ReactOS Newsletter #55

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

Know English?

Why don't you want to start to translate this material? You can invite your friends to help you.

* :

All can see and participate is translation


Font Engine

There is a difference between functional correctness and implementation correctness, a distinction one always has to keep in mind when saying something works in ReactOS. In the case of text rendering, while the output may for the most part look correct, the underlying implementation is nothing like how it should be. The abbreviated function call chain for displaying text is TextOutA/W, NtGdiExtTextOutW, and GreExtTextOutW. There are a few variations but the above provides a general idea of the path down to the Gre function. ReactOS on the other hand did not even have GreExtTextOutW and the Win32k module was actually calling NtGdiExtTextOutW. Since NtGdiExtTextOutW is the syscall that interacts with usermode memory and thus checks to make sure the buffers it is handed is in usermode, calling the function in kernel mode with kernel mode buffers should not work at all. This only worked because of another bug in MmCopyFromCaller, which is used to copy data from usermode buffers to kernel mode. This function was supposed to check a usermode buffer and copy the data to a kernel mode buffer. The check was broken, which was what allowed Win32k to use NtGdiExtTextOutW. In addition to all the above, MmCopyFromCaller should not exist. It is a ReactOS specific hack and NtGdiExtTextOutW should be using SEH to do the checking of buffers it receives. The reason Win32k is supposed to use GreExtTextOutW is that it is handing the function kernel mode buffers and GreExtTextOutW is also expecting to receive kernel mode buffers. Thus it automatically trusts whatever it is handled without any checking. This is very common amongst functions that are designed to work only when called from kernel mode.

The other thing ReactOS was not doing was using the STROBJ/ESTROBJ data structure, used describe a set of glyphs and their positions, essentially the text that one wants displayed. GreExtTextOutW calls the ESTROBJ::vInit to initialize the structure, also passing along the data to fill it in and doing the necessary coordinate translation. The

ESTROBJ::vInit function will also check the RFONTOBJ data structure for information regarding the glyphs of a font. Once this is all done, the STROBJ structure is handed to either the EngTextOut or DrvTextOut function. The Eng prefix refers to built in display functions in Win32k that act as backups in case the display driver did not implement a specific functionality, which in this case would be the DrvTextOut function. The problem in ROS however is neither the STROBJ or RFONTOBJ data structures exist so the entire rendering chain described above also does not exist. Furthermore, the ReactOS Win32k does not have an EngTextOut implemention and completely ignores a DrvTextOut function if it exists.

Timo Kreuzer has been working on rectifying this situation and has actually been sitting on a font driver for quite some time. The RFONTOBJ data structure mentioned above also acts as a cache for any glyph that has already been rendered. However when a glyph is to be rendered for the first time, a font driver associated with the RFONTOBJ structure is called. The font driver has a function called DrvQueryFontData which does the rendering for the glyph and either returns a bitmap or an outline. The next step is to implement the actual RFONTOBJ and STROBJ data structure and then rewrite the functions responsible for text rendering to use them. That should keep him busy for the next year or so.

Having explained everything that ReactOS is currently not doing, it would be negligent to not at least provide an outline of what it currently is doing, no matter how wrong it is. Instead of going through the font driver for the glyph information, all the above is bypassed and the Freetype DLL is called directly. And since the EngTextOut and DrvTextOut functions do not play a part in text rendering, GreExtTextOut simply calls on Freetype to render the glyphs and then uses either EngBitBlt or DrvBitBlt to display them. Another fine example of just how convoluted things are in the ReactOS Win32k.


As mentioned in the previous newsletter, Cameron Gutman has been working on the network stack after Art Yerkes finished the initial implementation. He has mostly been fixing bugs, such as the IRP cancellation that caused ping to hang. Much of his work was actually merged into the 0.3.6 and 0.3.7 release and were spread across multiple parts of the network stack. These ranged from making sure resources were properly allocated and deallocated and returning the proper status messages depending on successful completion of an operation


Ged Murphy recently set up a public Twitter group account where interested developers can make updates about the project. These updates will be sent via the normal tweet method and received by anyone following this account. Anyone who registers as a reactos follower will automatically become followed by the reactos account. This in turn means they are eligible to become involved in group tweets which will be propagated throughout all followers. To send a group tweet, you simply send a direct message to reactos as oppose to an @reply and GroupTweet will take care of the rest. Possible uses in the future include providing updates while at conventions.