Microsoft DirectX Runtime
First, let me state that legally, according to the whole Windows Genuine Advantage and EULA, you're not supposed to install the MS DirectX runtime on nongenuine Windows systems. On the other hand, the runtimes that come with various games as a prerequisite to playing the game aren't technically bound by the WGA. That aside, the MS DirectX runtime now loads on ReactOS. To get DX on, you need to manually copy the following files: dxg.sys, dxgthk.sys, dxapi.sys, ddraw.dll, and dciman32.dll. The installer itself still doesn't work and neither does 3D. However, simple 2D now works, with hardware acceleration. This is on VMWare Workstation where DirectX hardware acceleration is supported.
In order to get the runtime to work, a lot of effort has gone into fixing and implementing things in gdi32.dll and win32k.sys. Work on this actually started in 2004, so it's taken a while to reach this point. Thanks goes out to Magnus Olsen, Timo Kreuzer, Jim Tabor, Maarten Bosma, and Alex Ionescu for getting those components into shape and Kamil Hornicek for his help in testing the DirectX and ReactX components.
Keep in mind that this is Microsoft's DirectX we're talking about, not Wine's or ReactX. We can achieve 3D through using some of Wine's DX dlls. However, by running MS' runtime, we can test the implementation of functions in gdi32.dll and win32k.sys. All DX functions resolve down there anyways.
Major Bug Fixes
Not too long ago, Alex Ionescu tracked down a series of timing and locking bugs in ReactOS. These ranged from completely broken algorithms to just changing the type of lock used in certain situations, eliminating race issues, deadlocks, and other nastiness. The performance boost in certain situations were just obscene, with a boost of 150% during installation according to Alex's tests. Other major fixes were applied to the memory manager, replacing hacked code and various optimizations. Needless to say, we're all greatful for the help.
To those of you wondering why Alex is still developing for ReactOS, here's the explanation. First, the bugs in the locking code were actually fixed by Aleksey Bragin. Alex simply supplied the information and pointed out the problem spots. The code he did contribute was in fixing memory management problems. However, the memory management component of ReactOS is the biggest hold over from before the massive kernel rewrite to make the system behave more like NT. As such, even though our memory manager provides the same functionality, it is nothing like the NT memory manager. In fact, if you read the Windows Internals book and tried to work on the ReactOS memory manager, you'd have a rough time of it, something I can personally atest to. Fixing bugs in existing code is certainly permissible, as it's not that hard to spot bad code just by reading through it.
A while back, a programmer named Carlo Bramini began putting together a calculator program using the Windows API. He didn't like the Wine calculator we were using and decided give more funcationality to his. Well, congratulations Carlo, cause it's now part of the included apps in ReactOS. We thank you for all your work in programming it and hope to see future contributions from you. Carlo's calculator is included as a base application, while the Wine Calc has been moved to RosApps.
Dmitry Chapyshev added a way to do keyboard switching, a request many people have made. This is still a temporary measure, as the proper implementation will need to wait until we have a proper Explorer shell, as it's supposed to be a toolbar of some sort. Still, this is greatly appreciated by people who don't use the US keyboard layout.
Keeping in mind that we said the earliest a release of 0.3.5 would come out is April 2008, those of you curious as to what the hold up is, we currently have about three to six blockers that need to be resolved. I say three to six because Aleksey may decide to demote some of them or they might have been fixed already with the memory management patches from Alex. More testing is needed. Also, I'm currently in exam mode so the time I can commit to wrapping up changelogs is limited. Hopefully, by the end of next week, everything will be taken care of.