<?xml version="1.0" ?>
<kc>
        <title>ReactOS Traffic</title>
        <author contact="mailto:reactos@tong-web.com">Zach Tong</author>
        <issue num="1"
               date="14 Nov 2004 00:00:00 -0800" />
        <intro>
                
<p>There has been talk recently about a ReactOS newsletter in the tradition of 
                <a href="http://www.kerneltraffic.org/">Kernel Traffic</a> or 
                <a href="http://winehq.com/?issue=back">WineHQ</a>. At the same time I began investigating the ReactOS scene in hopes of helping.
                Unfortunately, my C/C++ skills are not up to par. Steven Edwards suggested I work on the ReactOS newsletter, which until this point,
                was absent from the ReactOS scene. Thus Splash was born.</p>
                
<p>Splash is the official ReactOS newsletter. Each issue will highlight and cover the interesting points that happen on the mailing
                list. It will also cover, when I can decipher it, the activities on CVS and IRC. Issues are planned to be released on a roughly
                bi-weekly basis. This project will be a learning project, a get-better-as-time-goes project. I have little experience with writing
                technical newsletters, and even less with ReactOS itself. Fortunately, time should help my judgment and writting. I hope you enjoy
                Splash. If you have any questions, comments, concerns or hate mail, please send it to: 
                <i>reactos (at) tong-web (dot) com</i>.</p>
                
<p>An alternate layout of Splash may be found <a href="http://www.tong-web.com/splash/index.xml">here</a></p>
        </intro>

		<section title="KDBG in VMware, kmode exceptions"
                 subject="[ros-dev] What is difference in installation procedure w/wo DGG, KDBG set?"
                 archive="http://reactos.com:8080/archives/public/ros-dev/2004-November/000610.html"
                 posts="9"
                 startdate="17 Nov 2004 00:00:00 -0800"
                 enddate="17 Nov 2004 00:00:00 -0800">
                
<p>David reports that he has been unable to install ReactOS with DBG=1 and KDBG=1 enabled. This happens because KDBG is designed to
                treat all exceptions as kmode exceptions. In this case, the VMware detection routine attempts to perform an instruction, that on
                normal systems, would raise a umode exception (or nothing at all if on a VMware system). Unfortunately, KDBG treats the umode
                exception as kmode, and goes 
                <i>*boom*</i>, regardless of it is actually running on VMware or not.</p>
                
<p>At the time of this writing, Art said he would commit a change to KDBG that would allow configuration of umode exception catching.
                General consensus (on IRC) seems that this is a good idea, and furthermore, configurable at runtime rather than compile time.</p>
        </section>

		<section title="Support for NIC Realtek"
                 subject="[ROS-Dev] Support of NIC Realtek 8139"
                 archive="http://reactos.com:8080/archives/public/ros-dev/2004-November/000588.html"
                 posts="8"
                 startdate="16 Nov 2004 00:00:00 -0800"
                 enddate="17 Nov 2004 00:00:00 -0800">
                
<p>Gerard conducted some testing on the Realtek 8139 NIC. He reports that the detection/enumeration of the third PCI bus (PCI BUS 2)
                has been fixed (thanks to Eric Khol, bug 
                <a href="http://reactos.org/bugzilla/show_bug.cgi?id=436">#436</a>). Additionaly, he reports that the RTL8139.SYS loads successfully
                but does not start properly. This is due to a unimplemented function in ROS, "NdisMQueyAdapterResources" (new bug, 
                <a href="http://reactos.org/bugzilla/show_bug.cgi?id=446">#446</a>). Filip offered a workaround (
                <a href="http://www.volny.cz/xnavara/rtl_bins/io_res.patch">io_res_patch</a>, 
                <a href="http://www.volny.cz/xnavara/rtl_bins/">binaries</a>) as well as an 
                <quote who="Filip Navara">"example filter driver that implements PnP Arbiter for Windows"</quote>(available 
                <a href="http://www.volny.cz/xnavara/arbfilter.zip">here</a>). Filip also requests that someone adapt and implement the code for
                ReactOS, as he doesn't have time.</p>
                
<p>Despite the workaround, it appears that the driver still does not start properly.</p>
        </section>

		<section title="ne2000.sys bug fixed"
                 subject="[ros-dev] Our ne2000 driver and tcpip"
                 archive="http://reactos.com:8080/archives/public/ros-dev/2004-November/000573.html"
                 posts="1"
                 startdate="14 Nov 2004 00:00:00 -0800"
                 enddate="14 Nov 2004 00:00:00 -0800">
                
<p>The ne2000.sys bug that was previously causing problems has now been resolved by Arty. A structure in ne2000.sys, named
                PACKET_HEADER, was previously thought to hold the ethernet frame header. After some digging, Art discovered that it is merely 4 bytes
                and only held which buffer page to use next. This was assigned by the ne2000 hardware, and had nothing to do with the ethernet frame
                itself.</p>
                
<p>Art says he has 
                <quote who="Art Yerkes">"now factored in the ethernet frame header and made tcpip work the right way, that is to remove consideration
                of the ethernet frame header at layers above lan in the receive pipe. This should make all adapters work the same way for larger
                packets (and ne2000 now work right)."</quote></p>
                
<p>Art used what Filip said, as well as examples from 
                <a href="http://cvs.sourceforge.net/viewcvs.py/openh323/pwlib/tools/PacketVxD/epacket.c?rev=1.2">here</a>, to fix the bug.</p>
        </section>

        <section title="Ekush forks ReactOS, GPL Violation"
                 subject="[ROS-Dev] Ekush"
                 archive="http://reactos.com:8080/archives/public/ros-dev/2004-November/000512.html"
                 posts="25"
                 startdate="09 Nov 2004 00:00:00 -0800"
                 enddate="10 Nov 2004 00:00:00 -0800">
                
<mention>Filip Navara</mention>

<p>G&#233; van Geldorp noticed that 
                <a href="http://www.ekush.com">Ekush</a>( 
                <a href="http://216.239.59.104/search?q=cache:zVauACrLkV8J:www.akshor.com">Google Cache</a>), a project designed to do the same as
                ReactOS, had published its binaries. After some simple string searching in the binaries, it was determined that Ekush was in GPL
                violation for using ReactOS source without abiding by its license.</p>
                
<p>Jason Filby said he would write 
                <quote who="Jason Filby">"a letter explaining [ReactOS's] position (when their site is back up) with appropriate links to fsf.org and
                perhaps eff.org."</quote></p>
                
<p>Thomas Weidenmueller describes why Ekush is violating the GPL, saying, 
                <quote who="Thomas Weidenmueller">"Remember, we still own the copyright, we just permit others to use the sources as the license
                says. Which, as I understand it, implies they must not remove copyrights, neither from binaries nor from sources."</quote>After some
                more investigation, Filip Navara discovered that they had also included 
                <a href="http://fabrice.bellard.free.fr/qemu/">QEMU</a>(licensed under LGPL). QEMU was renamed to EmuPC. There were references to
                FreeType and Wine as well.</p>
                
<p>But the plot thickens. G&#233; van Geldorp reports that shortly after the first email was sent to the ReactOS mailing list, the
                site went "Down for Maintenance". The next day, the site came back up with new binaries. The references to ReactOS mentioned by
                G&#233; van Geldorp were all gone, minus a few. Geldorp submitted a story to Slashdot which highlights the code theft (available 
                <a href="http://slashdot.org/article.pl?sid=04/11/10/1320231&amp;tid=201&amp;tid=190&amp;tid=1">here</a>) and Anich Gregor put
                together a list of identical ASM code between the ReactOS and Ekush (which can be found 
                <a href="http://blight.eu.org/reactos/ekush-tskswitch.html">here</a>). It appears that the Ekush website is now down. Whether done by
                Ekush itself or its hosting company is not known.</p>
        </section> 

	    <section title="Recent CVS Activity"
                 startdate="16 Nov 2004 00:00:00 -0800"
                 enddate="17 Nov 2004 00:00:00 -0800">
                
<p>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.</p>
                
<p>
                        <ul>
                                <li>bootdata/hivedef.inf - Create PaintDesktopVersion key and set it to 0. Win32k was trying to read this value and
                                gave an error message because it did not exist.</li>
                                <li>Fixed I/O Manager Bugs. APCs were not created with the right parameters in the right places, or had useless
                                parameters being sent.</li>
                                <li>Memory Manager: Fixed calls to KeAttachProcess/DetachProcess to typecast PKPROCESS</li>
                                <li>Kernel Services: Rewrote APC Implementation</li>
                                <li>Added new patch for Alex's BindImage, Map and Load and friends to CVS for next merge. This patch applies clean to
                                Winehq tip.</li>
                                <li>transport/tcp/* - remove some spew, eliminate deadlock condition (calling afd with socket locked).</li>
                                <li>NdisTransferData does not count header size when figuring out how many bytes to copy. Most of the tcpip code
                                does, so we do something wierd here. We must fix this later in a better way.</li>
                                <li>udp.c - Header size adjustments corrected. Port allocation added.</li>
                                <li>drivers/net/tcpip/tcpip/dispatch.c (DispTdiListen): Pass the right connection object to TCPListen.</li>
                                <li>tcpip: fix for udp socket close.</li>
                                <li>afd.h - UpdatePollWithFCB now runs at DISPATCH_LEVEL in every case. Added handle locks so we can signal and check
                                handles properly</li>
                        </ul>
                </p>
        </section>

</kc>

