Yes, that's why I always tell, and will do keep telling: Test your
code against a solid base! If you develop a driver, debug and test it
in Windows, and then fix ReactOS. If you develop an application or
CPL applet, develop it in Windows, and then fix ReactOS if needed.
Fortunately, that seems to finally work, and there are places we can
trust (there are many which we can't - yet). Certainly, the old
ReactOS way of "let's hack driver to fit hacked kernel" has gone long
time ago, and that was the case of "solving all problems at once".
One more thing - wine test fixing week, or other common-problem-
fixing week is a nice thing, and I think we really could do some.
WBR,
Aleksey Bragin.
On Apr 9, 2009, at 12:56 AM, Olaf Siejka wrote:
I`ll participate in testing team, no matter what shape
or methode
will be chosen, this is above discussion. The approach should be
discussed though.
In the years i`ve been with ROS, we had a remarkable increase in
stability, from the point when you had to be careful to finish up
the planned test, so ReactOS doesnt hang in the process, to the
point when you actually have to try hard to crash it. Certainly, we
are stilll miles from being rock solid, but the progress has been
made. We have one primary problem with our project: too many
problems at the same time. Its not only stability (with Mm, Cc and
vfat issues) or hardware support (unimplemented PnP and HAL, busted
resource reporting), or Win32 subsystem issues Timo has pointed. At
the same time we have problems with WINE userland and their
approach to implementation, general code untidyness, header mess,
miriads of old and often undocumented hacks, on which future
assumptions were made, rbuild/compiler issues, lack of decent
debugging tools, general lack of manpower in all areas, lack of
standarised testing platform as well as problems determining our
future goals or attracting more publicity. I think you could add a
bunch more.
You know what? We try to solve all of those problems at once. And
yet we are unable to finish off a single one.