ReactOS Newsletter #71

Author: Z98. Link to original: http://www.reactos.org/ru/newsletter_71.html#sec1 (English).
ReactOS Newsletter #71

Translations of this material:

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

Text

Newsletter 17

NT USB Stack

Pre-Vista, the USB architecture started with a very low level usbport driver. This driver was the one that created device objects for each USB controller and received I/O Request Packets (IRP). Depending on which USB standard the controllers were for, usbport would call into one of three helper drivers, usbehci, usbohci, and usbuhci. The one actually sending those IRPs was usbhub, and these components constitute the lower levels of the USB stack. The majority of USB drivers distributed by companies for their various peripherals sit on top of these and take advantage of a support library called usbd. Without the lower levels, proper USB client drivers won't work and this is what is meant by the developers when the current USB drivers are referred to as somewhat hacky.

Michael Martin has been working to implement these lower level components. Currently he has written a basic usbehci driver and is testing it by trying to replace the usbehci driver in Windows XP. Michael is reusing some code from the pvdrivers that are part of Xen, though there is a distinct limit to how much code is out there for such low level components. Few third parties have a need to implement something like this so much of the work has to be done from scratch. So far Michael has had some success getting the XP PnP manager to interact with his driver, though as the usbehci driver is only a single piece of the stack more time will be needed to get anything close to a complete stack.

Build Tools

When building the objects, the GCC compiler adds an underscore to the start of function signatures, with the linker expecting that underscore. This however prevents linking with objects generated by Microsoft's C/C++ compiler, which Timo Kreuzer wanted for his x64 branch. There is a configuration flag, -fno-leading-underscore, that keeps GCC from doing this, but it must also be passed to the linker and all libraries used must also be built with this flag. ReactOS makes use of several prebuilt C++ libraries in the build engine and they were originally not built with that flag. To fully fix the issue, as the binutils and GCC itself still were not correctly behaving even with the flag passed in, required some additional patches to those tools. Kai Tietz from the MinGW-w64 project helped provide the fixes, which allowed Timo Kreuzer to remove the hacks he had started adding to compensate for the problem.

Besides working on the header reorganization, Amine Khaldi has been working diligently on Clang and LLVM to build ReactOS. There are a variety of bugs in Clang that prevents this right now and the report here is acting as an umbrella for the ones Amine has found so far. Two have been fixed so far and Amine has been in continued contact with the Clang developers about the other issues. Either way, having more options to compile ReactOS on is always a good thing. There has also been some discussion on the Clang/LLVM mailing lists on adding support for structured exception handling, which would be very helpful to ReactOS in the long term, as Microsoft's compiler is one of the few that actually supports SEH. Without some kind of SEH support, using Clang and LLVM to build ReactOS will be impossible. Porting the Portable SEH library written by KJK::Hyperion would also be an option, though the port would more or less be a rewrite as the mechanism used to achieve SEH would be different with Clang and LLVM.

© ReactOS Team. License: FDL