ReactOS Traffic #3 For 8�Dec�2004

By Zach Tong

Table Of Contents

1. New ReactOS Forum

�Archive Link:

The ReactOS web crew has put up a new forum (powered by phpBB), which is far superior over the old one. Have a look here ( .

2. Tribes!

5�Dec�2004 (5 posts) Archive Link: "[ros-dev] Tribes1 Loads!!!!!"

People: Steven Edwards

What good is an operating system without games? Steven Edwards anounced that ReactOS loaded Starseige Tribes, albeit with a bit of coaxing:

"I just tested Starseige Tribes under ReactOS and it does load. You need dsound.dll and dinput.dll from Wine. GreatLord is working on fixing these to work under Windows and ReactOS now. If you want to test it tribes is a free download you just may need to do a google search. Make sure you set the graphics to GDI under Windows and then copy your config over. Of course the mouse wont work under ReactOS until GreatLord is done with his dinput changes. I have not tested with ReactOS new direct input as I am short on time tonight. I will try that tommrow."

3. Boot failure on Realtek8139

5�Dec�2004 (5 posts) Archive Link: "[ros-dev] Ros boot failure with networking enabled in real hardware - ed 2 with tcpip traces"

People: Art Yerkes

Gge reports that the current CVS (as of Sunday Dec. 5th) will not boot with the Realtek8139 NIC driver enabled in Hivesys. It should be noted this was on real hardware, not emulation. Art Yerkes offered a patch and commented on the bug: "My feeling is that TransferDataComplete is being allowed to run parallel with the work item. The only way i can see this happening is if somehow a buffer is reclaimed before its fully freed. This does seem to be the same bug as before but i'm not convinced its a regression so much as the same bug having been recently hidden and then reexposed."

Gge said that the patch did not fix the problem. Sylvain Petreolle has the same hardware and reports the patch does not work for him either.

4. ReactOS on XBox - Update

30�Nov�2004�-�3�Dec�2004 (15 posts) Archive Link: "[ros-dev] HAL reorganisation"

People: Ge van Geldorp,�Steven Edwards,�Maritn Misuth,�Alex Ionescu

Ge van Geldorp has been fiddling with getting ReactOS on the XBox: "I think most of the differences between a standard PC and the Xbox can be handled by using a custom HAL for the Xbox, after all, that's what the HAL is for. At the moment, we build 1 HAL, based on the value of MP in config it's either a UniProcessor HAL or a MultiProcessor HAL. Which code is compiled is based on preprocessor statements. I'd like to be able to build 3 HALs in parallel, the UP, MP and Xbox HALs."

Alex Ionescu noted that a new kernel will probably be needed to sucessfully get ReactOS on the XBox. This is because, despite how hard Microsoft tried, the kernel is still architecturally dependant to a degree. Furthermore, between Steven Edwards and Alex, they decided that ReactOS on the XBox would be complicated by the lack of BIOS, proprietary graphics, lack of legacy I/O, proprietary PnP, etc.

Steven eplains a little more about the propietary graphics: "[It] is a standard NVidia GeForce Chip minus a VGABios. VBE works fine on it and we have been in discussion with the xbox-linux people about how to trick it in to working with the Nvidia windows binary driver. The Windows driver supports everything from the old Riva cards up through TNT, GeForce[2,3,4}, etc. All we have to do is add a few hacks to videoprt.sys, the HAL and a few other places and it should load according to the research I have done. They have not done this on Linux already because of lack of resources."

GvG hopes that "it won't be necessary to put Xbox specific code in the kernel, but I'm not 100% sure about that."

Maritn Misuth brings up an interesting question regarding how ReactOS will behave under the XBox: "I've heard that XBOX WinNT kernel implementation has only around 120 kb in mem, allows single process only, (propably windows messaging) is done by polling and has not memory protection, so games can access hardwae directly. Will ReactOS on XBOX mimic this behavior?" This was answered with a definitive "No". The XBox port is meant to run ReactOS on the XBox, not to create an XBox OS. It should be noted that the port of ReactOS is not mean to run XBox games (like the XBox WinNT kernel port by Microsoft), but merely to run ReactOS on the hardware.

5. Bison!

30�Nov�2004 (13 posts) Archive Link: "[ros-dev] Must Read!!!! Msi.dll and Bison Alert!!!!"

People: Ge van Geldorp,�Steven Edwards

Jim Tabor writes in to tell everyone that ReactOS would begin using bison to build cond.y and sql.y. This was met with mixed feelings (predominantly negative though). There is much anxiety about getting ReactOS caught up in various build tools, compatability problems, extra dependancies, etc. GvG proposed a solution: " How often do we expect the .y files to change? Wouldn't it be much easier to put the generated files (*.tab.c and *.tab.h) in CVS? Developers actually modifying the .y files would then need to install bison, but that seems reasonable to me."

There was some more scuttle and argument, but GvG's solution was generally accepted. Lastly, Steven Edwards makes some good points for Bison (amid the flurry of disaproval voiced by everyone else) here ( .

"The issue I worry about is people not submitting stuff back toi Winehq and having thier code get lost in the merges. I have some ideas about how to deal with this problem but I need to talk them over with GvG, Eric, Filip and others that have done a lot of work on ported Wine code."

6. FPU State bug

27�Nov�2004�-�28�Nov�2004 (13 posts) Archive Link: "[ros-dev] Re: [ros-diffs] [CVS reactos] - Saved the state of the fpu at a win32 call and restored the state"

People: Hartmut Birr,�Gregor Anich

Gregor Anich asks Hartmut Birr why he has changed the w32 callback to save the FPU state. Hartmut replies by saying "I've made this changes, because syssetup does always crash ros in KiHandleFpuFault line #462 on my smp machine. The crash is triggered from fxsave in tskswitch.S after a win32 callback."

After some poking around the code, Hartmut decides that "it seems that my problem is in w32call.c line #143. We should not set the TS if Thread->Tcb.NpxState is NPX_STATE_DIRTY. On a thread switch the fpu state is saved because NpxState is NPX_STATE_DIRTY. This triggers the fpu exception. If I remove this line it works again."

Gregor tested this and also confirmed that the crash was due to this line. It was fixed and committed

7. ELF in ntoskrnl

25�Nov�2004�-�29�Nov�2004 (13 posts) Archive Link: "[ros-dev] ELF mapping support for ntoskrnl, for anybody who is interested (untested)"

People: Gregor Anich,�Steven Edwards,�Anich Gregor

Gregor Anich has submitted a patch to ntoskrnl that adds ELF mapping.

"I have attached a elf.h file (to be put into the toplevel include directory) with ELF structures/constants and a patch for ntoskrnl/mm/section.c which should add support for mapping ELF files with NtCreateSection. It is completly untested I think."

Steven Edwards hopes that by adding "ELF support to ReactOS we will make porting ReactOS almost as easy as it is to port Winelib to another platform."

There was some discussion on the thread as to what exactly a mapper does. Anich Gregor explains for us what it does, and how it works (in a nutshell): "When an ELF file is loaded it is mapped into memory, then the kernel looks if there is an interpreter (a filename like /lib/ and if there is one it also maps the interpreter file into memory and starts execution at the interpreter's entry point instead of the executable image to be loaded. The interpreter (rtld - runtime link editor) relocates itself and the executable image, sets up other stuff and transfers execution to the executable image's entry point. On windows (for PE files) ntdll is doing that."

Lastly Gerardo Garc�a Pe�a posted a thread that gave a veritable gold mine of information regarding ELF, which can be found here ( .

8. Recent CVS Activity


This section contains nothing more than interesting CVS comments that I personally like. There are more CVS comments then listed here, and many more actual commits.

Quote of the day:

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.