
The text of the translation of the news under the cut, but here is a small advertisement request.
Support ReactOS at Lenovo Competition
Help the project win a ThinkPad X1 laptop and $ 25,000 for development. Today is apparently the last voting day.
Alexey Bragin (project coordinator) will be especially pleased to receive your support, because yesterday he celebrated his birthday.
For this you need to spend only two minutes of your time:
1)
donetwork.lenovo.com/en/login.html - by this link, log in with facebook;
2) go to
donetwork.lenovo.com/ru/projects/view/id/2977 and click on the “vote for the project” button;
3) leave a comment if you like, click on Facebook like and +1 Google ...
4) ... the pace of voting is very good, but there is a risk of not having time, so please share this news with Habr in your twitter and contact (buttons at the bottom of the publication next to the vote).
To get ahead, the project needs to gain not so much - at least 250
0 votes. (fast figure by habr standards)
')
Wireless network
Cameron Gutman has been busy with developing the components needed to support ReactOS's wireless network cards for almost the entire past month. Much of the work involved writing the NDIS protocol driver (ndisuio), which supports the transfer of NDIS object identifier (OID) messages. These messages are designed to query network drivers about their status and capabilities, as well as to set the receive mode in which the device should operate. In addition to code in kernel mode, a user mode utility is required that allows end users to make these requests. Currently, ReactOS includes the wlanconf utility, which supports mapping network adapters to ndisuio. In addition to all this, work was carried out on the DHCP service related to the quick completion of requests for release and updating of IP addresses, as well as the TCP / IP driver, which will make sure that the OID messages are used correctly when checking the status of a network device.
Due to the upcoming release of version 0.3.14, Cameron added the results of his work to the code base of the project, and now fresh ReactOS assemblies can connect to open wireless networks as well as wireless networks using WEP encryption, which indicates that the network driver is functioning correctly. Networks with more reliable types of encryption, such as WPA and WPA2, require the operating system to provide a more complex communication process, but this functionality is not yet available in ReactOS. However, the current state of support for wireless networks represents a big step forward in terms of ensuring the suitability of ReactOS work on modern equipment.
USB support status
Johannes Anderwald recently did a lot of work on the USB stack, which he started with Michael Martin, and completed the development of two of the four host controller interface drivers needed to support the standards currently in use. ReactOS currently has ohci for USB 1.1 and ehci for USB 2.0. The project now needs uhci to support the Intel standard for USB 1.0 interface, and xhci to support the new USB 3.0 interface. In addition, the HID driver (human interaction devices) for mice was completed and tested in Windows, but many different problems in ReactOS hindered its functioning. The HID driver for keyboards is also in development, but not yet ready. Support for storage devices will require additional drivers. Another missing element of the USB stack is support for composite USB devices, such as the combined keyboard / mouse connector.
Cameron, who came to the rescue at this stage, investigated a large number of errors during the registration and installation of devices, and also engaged in fixing problems that hampered the operation of the USB mouse in ReactOS. He also eliminated several other problems directly in the USB stack, starting with critical system crashes and to errors when compiling various components. Johannes expects that now, thanks to the corrections of Cameron, the implementation of keyboard support in the system should not cause difficulties. As soon as the USB branch is well tested and integrated with the main code base of the project, ReactOS will take another significant step forward in terms of usability. This step, however, will be taken after the release of 0.3.14.

Read more about the current USB state on the
wiki.UPD twitter.com/# ! / Reactos / status / 162638367970963456 - installing ReactOS on a USB flash drive.Shell32
Rafal Harabień (Rafał Harabień) was busy working on the shell32 library, eliminating various problems, starting with errors loading icons and dialog boxes, and before fixing a lot of buffer / memory errors. To load icons in the properties windows, an incomplete implementation of code that already existed in shell32 was used. Rafal removed the corrupted code and changed the properties window to use the implementation already in shell32. Now the property window is able to load any icons, not just those that have been specified in the registry. The code for the Open With dialog box was also rewritten, which allowed to show all applications specified in the registry. The dialog box will no longer also add duplicate entries to the registry. However, it remains to spend a huge amount of work on the shell32 library before it and explorer_new can replace the current shell. For example, the Start menu is not documented and is not implemented in ReactOS, so Rafal does not know exactly how the responsibilities for viewing the contents of folders between the explorer shell and the shell32 library are divided. Until these problems are fully resolved, ReactOS will remain its current shell.
File system corruption
Pierre Schweitzer recently rewrote the code in dir.c, triggering the discovery of a problem that had already existed before - writing damaged data to disk. Investigating the problem, Pierre noticed that one of the testers had already encountered a similar problem and provided a debugging protocol. This protocol, however, indicated that the reason for this behavior was a different function, and not the one that Pierre himself discovered during his own research. Upon closer inspection, Pierre noticed that both the guilty functions caused another internal function in the runtime library that processed the paths. This function was one of several that Alex Ionescu worked on during the processing and correction of the code, but he never finished the work. As a result, the failure of the old code, coupled with Pierre's own changes, somehow provoked damage to the file system. Pierre finished the work begun by Alex, and the problem with the damage seems to have disappeared, although he still didn’t fully understand what was wrong with the old code and caused the file system driver to write corrupted data to disk.
PS Translated except me:
evilslon ,
seven_roAlready collected more than 9,600 rubles.
The following proposals were received from the list of relevant and adequate:
*
Support for all SATA drives. Well, or at least popular.*
Be compatible with .net 2.0 apps or be able to install Framework.*
Though I am sitting on * nix, but I supported hundreds for Multimonitor support.Several people asked for support for themes, but this feature has already been implemented almost completely.