Home | Info | Community | Development | myReactOS
|
|
Community > ReactOS Newsletter Archive > ReactOS Newsletter: Issue 20ReactOS Newsletter - Issue 20 (#20)
by Z98 on 2007-03-18 topA Third IntroductionGood day to all. The name's Z98 and I'm one of two release managers for ReactOS. The source files and QEMU images were generated by me, so if there are any mistakes, you know who to complain to. Today I wrote most of the newsletter and I will be helping samwise52 in the future. topReactions to 0.3.1Reactions have varied in regard to 0.3.1, though one response was consistent. The difficulty in getting it to work on real hardware. As mentioned many times, 0.3.1 was branched in the middle of a kernel rewrite. The resulting instabilities weren't totally unexpected. Also, there was supposed to be alpha blending in 0.3.1, but apparently someone broke that and no one noticed before the release. Still, 0.3.1 drew a lot of publicity from many people and sites, which helped to raise awareness for ReactOS. One thing that I believe should be clarified is the goal of ReactOS. While officially it's stated to be XP/2003 compatibility, in reality, work is also done to make it Vista compatible. Many Vista specific implementations have already been stubbed and will also be worked on as more things stabilize. So ReactOS will not become an implementation of an outdated Windows version. It will continue to follow Windows as best it can. topWinDBGSupport for WinDBG was mentioned in issue #18, and we'll discuss it in more detail here. For some time, Alex Ionescu has been working on supporting the use of WinDBG in ReactOS. Most of this work was done in a branch of the source but recently they were merged into trunk. Alex has reported that it is now possible to use WinDBG to connect to ReactOS, set breakpoints, display trace information, print DPRINT output, and step through the code. The use of WinDBG deprecates KDBG, GDB, and other old settings for printing to screen and file. Still, the old debugging system will remain in place for continued usage. Also, with WinDBG, ReactOS would be using the same tools Microsoft uses to write Windows. These should help greatly in finding bugs as well as reduce some of the hidden bugs in the debug systems. topDirectX/win32k/ReactXWe're slowly getting there, especially in the 3D department. GreatLord's use of the 0.3.1 branch while testing certain aspects of win32k for his Direct3D work tripped the PSEH loop that delayed the 0.3.1 release, which is now fixed. So far, work on DirectX is stalled because of more bugs found in win32k. One specific issue arose in creating surfaces. GreatLord's made a lot of progress on fixing that and things are improving. As these get sorted out, we'll see speed increases as well as more stability. A name was also chosen for the ReactOS DirectX clone. As many people probably suspected, ReactX or ROX(shorthand) was chosen. A logo will be chosen sometime after 0.3.2 is branched, so keep on posting those ideas.top Website TranslationsOver the past few months, several people have asked for permissions to translate parts of the ReactOS website. At times response to those requests have been slow, creating some frustration. Frik85 has another system in the works but while he's getting that set up, I(Z98) have created a temporary measure. SoundSome of you might have noticed in the Roadmap "Some initial support for audio." Well it's getting there. Developer Andrew Greenwood aka Silverblade is hard at work implementing the Kernel Streaming APIs that are the mainstay of the Windows XP sound architecture. Although this architecture is changed in Vista, Kernel Streaming is still at its base. The major difficulties of the Windows sound stack include the use of C++ and COM kernel mode, needless to say filled with countless pitfalls and possible problems that will stress not only the system but also the programmers themselves. This still isn't a user visible change, as your sound card drivers will still NOT work. But as ancient wisdom holds, even the longest journeys begin with a single step. This is a very important part for the future user friendly ReactOS. Events in SVNTrunk has been incredibly unstable recently because of kernel changes and other commits. One major improvement was to allow two devices to share a driver, thus negating the need to load two drivers. This saves memory and helps increase speed. A bug in the improvement broke trunk for a while but Hervé Poussineau managed to fix it. Another major issue that's cropped up is with named pipes. For those that don't know what named pipes are, they're used to communicate between processes. They are also used to communicate with the PnP manager. Needless to say, the breakage is something of a serious problem. Whatever is causing it is also the root of the VMware problems. The devs aren't sure what the cause is, though some speculate it to be a timing issue. A third effect of this issue is causing ReactOS to hang for about a minute before the explorer shell is fully initialized. And just recently, libcntpr got broken.
Bugzilla57 bugs were active. top |
, Website Coordinator: Klemens Friedl 
Edit page content (RosCMS translator account membership required, visit the website forum for help)
