Alex Ionescu has an important announcement about a program he is starting to further ReactOS:

"

Dear ReactOS enthusiasts and friends,

We are currently in dire need of motivated people to help us build the future OS of the masses. While our developers are busily creating new code and fixing bugs, there remain dozens, if not more, of things to take care of in our tree and in our code. I would like to extend an open invitation to anyone interested on becoming a JANITOR (Just A Newbie Intensively Training On ReactOS).

As a JANITOR, you will join a team of people, which, just like you, want to see ReactOS succeed and have some spare time to help. You do NOT need any coding experience! Most of the time, only simple word processing skills are needed. Janitorial jobs will include cleaning up comment headers, standardizing the debug system, alphabetizing code and organizing files, compiling a list of fixmes, checking for spelling mistakes, etc. These jobs will be custom tailored to your abilities, and there will be no time limits (but you must commit to doing the job).

Also, JANITORs will have access to an online collaboration site where the current top-priority jobs are presented, and where they can commit to one of them. You can also share the workload and work in teams, or however you work best. A status system will be available to monitor the progression of jobs, and many more tools will become available.

So don't delay, and join the JANITOR program today! Send me an e-mail at alex@relsoft.net with your name, e-mail and contact availability (MSN, ICQ, IRC (preferred)). A real-time communication tool will be preferred, but I can acustom to people demanding exclusively e-mail contact (since the JANITOR Project Site will have most of the information).

I know that many of you want to help but that the current state of the outdatedness of the website and documentation, as well as the general lack of directions are discouraging you. This will be a unique experience to leave your mark in ReactOS.

Best regards,
Alex Ionescu
ReactOS JANITOR Program Manager

NOTE to Devs: The JANITOR Program is fully the child of my brain and is a personal project, and will not use the ReactOS bandwidth, site, or other resources unless explicit permission and agreement is made by all developers. You will not need to do any additional task or handle anything more and this will not affect your workload in any way.

"

Dynamic 3GB

ReactOS now has Dynamic 3GB support. Before this change, ntoskrnl would have to be recompiled to switch between loading at 0x800000000 (the 2GB mark) and 0xC0000000 (the 3GB mark). Thanks to Alex Ionescu and Royce, recompiling is not necessary anymore. Now, a switch in freeldr.ini can be changed to dynamically change how ReactOS acts. The 3GB option changes how much memory is available to applications (either 2GB or 3GB).

SYSENTER Support

ReactOS now has SYSENTER support. For those that are not kernel developers (most of us), here is a brief explanation. Before this update, ReactOS used the Int 2e instruction to switch between kmode (kernel mode) and umode (user mode, applications and such). The Int 2e instruction uses both an interrupt gate and a code segment descriptor. This takes quite a few CPU cycles to complete and has high overhead. SYSENTER essentially hardcodes the memory location needed for kmode operations onto the CPU. This makes it much faster, and therefore offers a huge speed increase. It was reported that ReactOS gained a 70% speed increase (on syscall speed). ReactOS was also patched to enable SYSENTER on SMP machines.

For more information on the Int 2e instruction, look here. For information on SYSENTER, look here.

Native function protection

ReactOS now has the ability to protect itself from application crashes.

W3seek changed a lot of kernel functions to use ProbeForRead and ProbeForWrite to verify that buffers from umode (user mode, where applications reside) are good. If the buffers are not good, the function is returned to umode in failure, instead of using the bad buffers and crashing the OS. This allows the application to crash (worst case), but does not bring the OS down as well. This is crucially important to the stability of ReactOS and its ability to survive application crashes.

Compiling with Optimizations

By setting OPTIMIZED to 1 in the config file (inside the root folder of the ReactOS sources), ReactOS can be compiled with all optimizations on (and now successfully build) and now successfully builds and runs.

Art Yerkes has continued to increase the networking capabilities of ReactOS. The server side of TCP sockets is now in working order. A test case is located in the /rosapps/tests/netreg/ directory. Running netreg -p 2000 will open up a listening TCP socket on port 2000, localhost. You can then connect to it (http://10.0.0.100:2000/, etc) and see an HTTP representation of the ReactOS registry.

There is now support for SOCK_RAW IPPROTO_ICMP sockets that can send and receive on. This means ping is fully functioning (both send and receive).

Lastly, broadcast UDP is now working. This means that UDP packets setnt to the adapter broadcast address will also use the ethernet broadcast MAC. UDP packets received on the broadcast address match a UDP socket bound to the default address at the target port. This means boot-time tftp, bootp, dhcp, etc can work (but have not been implemented yet). It also means that nmblookup should be able to resolve netbios names.

Some news from Mark Tempel and Aleksey Bragin about the USB interface. You can keep track of USB progress at the USB wiki page.

"

After some thinking and talking to X-Box guys, I decided to try implementing part of ReactOS USB Stack with help of a Linux USB Stack, but in a very special flavour - which is abstracted from Linux kernel, and from hardware also (this implementation is used in Cromwell). So now we have two concurrent tasks going on:

1. Porting Cromwell usb stuff to ReactOS (I already make it compiling into usbcore.sys and ohci.sys - this all is placed at reactos/drivers/usb/cromwell/, but hardware interface needs to be changed to use HAL)
2. Creating compatible interface to higher level of USB drivers (e.g. Class drivers, etc) - so we can have compatibility with Windows XP here. This involves creating a usbport.sys driver, which have all IRPs and IOCTLs stubbed, and then we can fill it with calls to the ported usbcore.sys and ohci.sys.
3. Creating drivers for other host controllers (currently only OpenHCI? is done in Cromwell's usb drivers). Universal HCD would be a very nice thing to do, I think the best way is to get uhci hcd from linux stack, and adapt it to ReactOS.
4. Creating class drivers and other higher-level stuff -- we can test our lower level drivers with class drivers from WinXP.

"

Steven Edwards tells us that ReactOS now has a functioning web browser (in addition to Dillo, which has been working for a while). The browser uses the Gecko Layout Engine (used in Mozilla). To get it working under your ReactOS, do the following:

"

1. Add urlmon and shdocvw to the build
2. wget the mozilla control from here ("Url"="http://crossover.codeweavers.com/redirect/mozcontrol")
3. Install the control (It may fail a few times)
4. Copy msvcr70.dll to reactos\system32
5. start cmd.exe and cd to C:\program files\Mozilla ActiveX Control .....
6. type explorer
7. hit the webbutton

"

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

• Use the service contol pipe to send a start command in order to start a service thread.
• fixed InbvPutPixels() to save the ebx register which caused bootvid to crash when built with optimizations
• Suggested fix for atapi. The atapi driver wants whole sectors, but the ext2 driver sometimes attempts an incomplete write. Here we fill the remaineder of the sector with zeros. This isn't the most elegant way to do it but illustrates the problem. I'm committing this here because it's a branch.
• Avoid crash if import directory is messed up
• Fix declaration of WSAStartup
• Set up ACPI Interrupt data before creating the interrupt, to fix case where interrupt is being called as soon as it's being set up, before the data is set. Patch by tinus. Fixes bug 472
• RtlCaptureUnicodeString should also check the buffers that the UNICODE_STRING structure points to...
• Working ping.
• Fix crashing browsing namespace with non-zero-terminated UNICODE_STRING.
• Make NtFlushVirtualMemory return STATUS_SUCCESS rather than hanging as being UNIMPLEMENTED. Added a DPRINT to warn that its a stub
• HTTP registry browser.
• Added a port of BSD traceroute.
• Connect a pipes client side as soon as a listening server side is available.

Quote of the day:

• (I had a craving for C code, too much Java for school was melting my brain. Thanks god for good ol' tickcount)