ReactOS Newsletter: Newsletter 73

Author: Z98. Link to original: http://www.reactos.org/en/newsletter_73.html (English).
Tags: FOSS, GNU, Newsletter, ReactOS, windows Submitted by evilslon 23.06.2010. Public material.
ReactOS Newsletter 73 Timers and Messages Consoles and Blue Screens Managing Sockets Arwinss Back and Forth More Old Than New

Translations of this material:

into Russian: Выпуск новостей ReactOS №73. Translation complete.
Submitted for translation by evilslon 23.06.2010 Published 7 years ago.

Text

A word of advice to everyone, traveling through six different cities in the span of two weeks requires a careful balance between changes of clothes brought and lightness of luggage, though a willingness to hand wash will also go a long way.

Timers and Messages

Several years back when I first joined the ReactOS team as a release engineer, which I technically still am, the team ran into an odd bug where when downloading something in Firefox they needed to move the mouse to see any progress. Jim Tabor traced the cause to the nature in which timers were implemented in ReactOS, meaning the fix would be nontrivial. Years later he had completed most of the code for a new implementation and Michael Martin has applied a few additional fixes to make it operational.

Previously the only time the system would check for the expiration of a Win32k timer was when an application retrieved a message from the message queue. These messages are basically the notifications the operating system sends to the application to inform it of some kind of event such as a mouse moving. This meant if there were no messages or events the system would never check if a timer had expired. Firefox exposed this issue because it was trying to be clever and avoid the polling that usually happens in a Win32 application by using a timer to basically put itself to sleep. Jim's fix involved using a kernel timer that on expiration would force the system to check existing Win32k timers for expiration.

Consoles and Blue Screens

Perhaps due to the lack of applications that actually use this feature, consoles on Windows are capable of having multiple screen buffers. This is akin to how the less program on various Unix derivatives load the contents of a file in a new buffer and upon exit the user is dropped back to where he or she was originally. Previously in ReactOS consoles and screen buffers had separate bookkeeping and there was nothing that linked an inactive screen buffer to its parent console. This created a curious situation where the mere concept of switching between screen buffers did not make any sense. In addition, when a console was closed through FreeConsole, the screen buffers that it may have created were not cleaned up and a new console that was created through AllocConsole could pick them up. Besides being a resource leak, it also had the potential to be a security problem if used creatively.

Jeffrey Morlan reworked management of the buffers by adding a linked list to the console object so it could keep track of the buffers it owns. At the same time he added a reference to the parent console in the buffers themselves. This allows the FreeConsole call to find out about the buffers a console owns and close them, plugging that particular hole. In the process of fixing this he also encountered a bug in Windows itself, where deleting the last buffer in a still active console and trying to force it to switch to a now non-existent buffer would blue screen the operating system. This is obviously one behavior Jeffrey had no intention of emulating and currently just makes sure the last buffer will always stick around until the console itself is destroyed.

Managing Sockets

Cameron Gutman spent the last month continuing his work on the network stack. One of the more egregious items he fixed was how msafd stored socket information. Originally everything was put into a static 1024 element array, which effectively guaranteed a buffer overflow if an application opened more than 1024 sockets. In addition to this, the structure used to hold socket information was never freed even after the application was done with it. Combined, these two issues would have been a major impedement to scaling in ReactOS.

The static array was ditched for a linked list implementation which will allow the list of sockets to grow dynamically. On the premise that the newest socket created is the one that will be most used, new entries are added to the head of the list. Whether that assumption will hold in real world applications is another entirely, but in theory it should not cause any major decreases in performance.

Arwinss Back and Forth

There were three notable developments that came to fruition in Arwinss over the last month, highlighting the complexities of increased dependence on Wine. The first involved an effort the Wine project made to clean up mouse cursor icon support to make it more compatible and remove some of the last vestiges of 16bit code. It must be remembered that Wine started out as an effort to duplicate the 16bit Windows API and a lot of cruft accumulated because of this. After Aleksey Bragin and others modified the ReactOS side of Arwinss to support the changes, the mouse cursor became a black box. Even more curious, moving it over the window border would result in it turning into the correct resizing mouse icon. With Giannis Adamopoulos help, Aleksey confirmed that the issue was on Wine's side and was due to the bitmap of the cursor having already been selected in a separate device context. This error resulted in the duplication failure of all of the cursor bitmaps except for the resize cursor. Aleksey noticed that Wine had resolved a similar issue in another part of their codebase so he applied the same fix to the GetIconInfo function, though he has yet to submit a patch upstream. Still, this issue is a bit troublesome as Aleksey was not sure what other device context was hanging onto the cursor icon, which could imply some kind of resource leak.

The second two developments were part of an effort to rectify Wine's limited shell support. Most people using Wine rarely need this as they already have a separate running shell and few applications of interest to them make use of the shell functionality anyway. Trunk actually already has this functionality but as explained above supporting them was never a priority for the Wine project. One of the issues was the lack of shell hooks, whose lack was most visible in running applications not showing up in the taskbar. This is a fairly standard expectation so remedying it was considered a priority. The current ReactOS Explorer shell also had to deal with this missing functionality in the past and actually had a hack where it would poll running processes to see which had visible windows, adding and deleting them as it went. The correct way of doing this was through notifications from shell hooks on application startup and exit. Maarten Kroese, who is not yet a formal developer but well on his way to becoming one, has been busy implementing those hooks for Wine and intends to send them upstream and it will eventually land in Arwinss as well.

The last issue was the source of major frustration amongst Arwinss testers. When an application was started in Arwinss, clicking on the desktop would make all the applications disappear even though they were still technically running. This was not a matter of them minimizing but the desktop actually taking the foreground, something it is not supposed to be doing ever. The current fix being worked on by Giannis is something of a hack as it simply has Arwinss' window manager ignore all requests to bring the shell window to the foreground. Whether there is a more elegant way of doing this in Arwinss is still something that needs to be explored, but for the time being it should be good enough for usability purposes.

More Old Than New

Amine Khaldi is basically an old hand at this point as he has served as bugzilla maintainer for quite some time now, hounding developers about languishing bugs and patches. He recently stepped into developer shoes with his work on ReactOS headers and we expect more work out of him for quite some time. Jérôme Gardou on the other hand is a more recent addition to the team, but has already made great strides in the yarotows branch of ReactOS. A more detailed explanation of yarotows will come soon but simplistically it's another effort to get the Win32 subsystem into shape and progress has reached a point where merging parts of it back into trunk is bringing noticeable benefits.

© ReactOS Team.