[ros-dev] Restructuring ReactOS

Richard Campbell richard at connectivex.com
Tue Mar 10 18:59:12 CET 2009


Hi Guys,

One of the big issues I'm seeing with regards to ReactOS is the lack
of overall structure.  Currently ReactOS is loosely compatible with
NT, 2000, XP, and even Vista.  However, I believe that in order to
achieve true stability and compatibility some changes should be
implemented.  I'm offering my opinion as a suggestion of how to
structure things.  While I believe that everyone should be allowed to
have fun developing a great project, I believe that we can still do
this, while maintaining a little more structure.  Please feel free to
comment on this email.

First Issue:  Moving Target

Every since I first started watching ReactOS in 2001, I've noticed
that ROS is suffering from moving target syndrome.  Microsoft
continually releases new versions of Windows each year, and ROS
struggles to keep up.  driver compatibility, app compatibility, etc.
are all affected by this.  Development is all over the place.  If
someone knows how to implement a vista API call, they do it.  XP?
Same, etc.  The problem is this can cause compatibility issues with
drivers and apps that do DLL hooking, as well as other oddball
scenarios.  In order to have truely 100% compatibility, we need to
find a way to deal with this type of development.

I propose picking a single target, Either Windows XP or Windows 2003,
to serve as the trunk  (I currently recommend Windows XP since it is
compatible with nearly everything out there.)  All core development
will be based around this.  Our releases will be based around this.

Branches will be created for Windows 7, Windows Server 2008, and
Windows Vista specific code.  Any platform specific code will go into
this branch.  Any code that is no longer valid will be removed from
this branch.  This allows multiple versions of Windows to be targetted
at the same time.

The trunk will continue on it's path until a)  It is 90-100%
compatible with most apps/drivers or b)  XP/2003 become so old and out
of date they aren't used by anyone anymore, similar to the way
98/NT4/2000 are now.  If either of those scenarios happen, we vote to
switch to a different branch.  We should avoid switching to the most
cutting edge version of windows, however, and instead focus on the
most widely used version at the time.

Second Issue:  ROS Hacks

I've noticed that a lot of times, people implement app specific hacks
in ROS, or worse, they implement ROS specific hacks in different apps.
 Both of these are very bad practices.  Instead of doing either of
these, I'd recommend discussing the problems you find with the other
developers over the mailing list.  For instance, if app XYZ is
working, rather than submitting a hackish patch to get it to work,
find the root cause of the issue, and solve it there or ask for help
to solve it.

Third Issue:  Unit Tests

While there are winetests as well as other small tests, ReactOS (That
i know of, unless it's in a seperate repo) does not have an official
testing framework.  Each developer here should take some time out and
write a test for every api currently supported by windows, make it
pass on Windows, and then commit it to SVN.  If we all write tests,
This will help identify bugs in ROS vs Windows.  Low level tests are
ESPECIALLY needed.  Our driver compatibility currently sucks, and it's
getting worse every day.  Unit testing for driver specific APIs and
the HAL would help improve ROS dramatically.

Final Issue:  Stop mixing user and kernel mode code.

On occasion i see developers use ReactOS specific kernel mode code in
userland.  This process should be avoided.  All ROS apps should work
on both Windows and ROS, and should not contain any ROS specific
checks,etc.  This goes back to the second issue.

I look forward to hearing your responses to my opinion, and I hope
that we can work on getting at least some of these opinions
implemented so that we may build a truly great Microsoft Windows
Compatible Alternative!

Thanks,
Richard Campbell


More information about the Ros-dev mailing list