Hello,
Ok here are some proposed ground rules for the audit. Mostly thanks to
Art and Alex. We are still open for debate on this
0. Everyone needs commit all documentation you have reverse enginered
something so that someone else can reimplement it. Filip has some nice
docs at
http://www.volny.cz/xnavara/doc_trash/
There is stuff I posted on the Wiki and Bugzilla. Can someone make a
api-documentation module in svn and commit all this stuff to there?
1. A function is deemed to have been implemented in a non-clean manner if
- "unknown" arguments given values
- functions for which there is NO DOCUMENTATION
- functions with no test cases available either in ReactOS or
somewhere on the internet
- functions with undocumented magic numbers
- functions with excessive gotos
NO DOCUMENTATION means it cannot be found on MSDN, Google,
sysinternals, osronline, any book published by Microsoft Press or any
other publication.
2. The following does not count
- functions of 5 or less lines of code
- functions for which every basic unit corresponds to a clause in the
official documentation
- functions which mimic those implemented in other libraries and that
work similarly
3. Even if the function body is not clean, the prototype can remain.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
I thought it would be a great idea to put all the reversed engineered
documentation in a separate directory in the audited trunk.
Here is the diff to set it up (attachment).
Thanks.
Index: rev_doc/readme.txt
===================================================================
--- rev_doc/readme.txt (revision 0)
+++ rev_doc/readme.txt (revision 0)
@@ -0,0 +1,4 @@
+This directory contains the documentation from reverse engineering. Please do not put actual code here.
+Just enough to implement it. If you reversed engeneered it please keep the policy and do NOT implement it.
+
+Thanks.
\ No newline at end of file
Just a very, very vague question:
When can the public exspect access to a ( surely very leaky ) cleaned up
skeleton of ROS?
I mean that we have a running system, without the unchecked ( unclean )
components, so that people can start working again on the clean code.
For example: We can boot and explorer pops up. Nothing more. So we can
fix bugs in NTOSKRNL, FREELDR and EXPLORER...
Greetings,
Jan Schiefer
Hi,
as the repository is being set up fresh, I think this would be the
best time to correct some problems with the directory layout and file
naming schemes.
The rbuild input files have been named "*.xml". Yes, these files are
XML files. But it's not the best name for them. It would clash with
XML files being used by the built applications itself. So I propose to
rename all those "*.xml" files of the rbuild system to "*.rbld".
What do you think about this idea?
Regards,
Martin
Personally, my main area of interest regarding the recent discussions
has been that of reverse-engineering. But what I'm about to say could
probably be applied to the leaked sources, too (this isn't what I'm here
to discuss, however.)
We all know that some bits of Windows' internals are hidden, often
intentionally, and that some product may make use of certain hidden API
function calls, or may interact with the system components in a way
other than that described in the API reference documentation.
Other times, parameters to API function calls are not clear, or not
documented at all.
As a result, to make something that is compatible with Windows (or at
least MORE compatible), it is necessary to use alternative methods (eg:
reverse engineering) to determine what an undocumented function works,
how it behaves, or to investigate undocumented flags, etc.
For the sake of the project, any reverse-engineering should be done as a
2-man job. It seems the case that people often take it upon themselves
to do both jobs - that of the person looking at the disassembly, and
that of the person writing the code.
This is how I wrote most of WDMAUD.DRV.
I was skeptical about the morals/legality of it at the time, but was
told that it doesn't matter.
As this is all now out in the open, and I've exmained the disassembly of
WDMAUD.DRV, it's probably best that I continue to examine it, and
document my findings, for another developer to implement later.
For other modules, it depends who's comfortable doing disassembling. I'm
happy to write code, and would like to do so. But I haven't the first
clue about kernel-mode debugging so things like the Kernel Streaming
API, I'd probably struggle with.
As for the rest of the project, the impression I get is that, rather
than going through the existing code and auditing it, it might be best
to start over.
This has disgruntled a lot of the major developers.
But don't forget, when the project was in its early days it was focusing
on NT4 compatibility... Not a lot worked, and there was no clear-cut
development policy... Then there was an explosion of activity and we've
been racing forward ever since.
Some may claim we're reinventing the wheel again, but we already *have*
a working kernel and this time round it shouldn't be as difficult as it
was previously, provided we can use our original sources as a reference.
There's all sorts of things that can be implemented from the start
rather than being added on later (maybe translations? - I don't know how
this works but AFAIK this was something that was discussed further along
the development line.) We can focus on the current technology and not
aim low (NT4.)
I just think we need to have people who are good at deciphering
disassembly and producing documentation, and people who can code from
that documentation (or other documentation, of course.)
Anyway, those are my thoughts. If any of it doesn't make sense it's
because I'm tired!
What's the location of the new ReactOS SVN repository?
I tried 'svn co svn://svn.reactos.org', and I got an error saying that
no repository existed at that address, so I'm guessing the location of
the repository has moved.
...
I assume SVN is starting from Scratch?
On 1/27/06, chorns(a)svn.reactos.org <chorns(a)svn.reactos.org> wrote:
> Standard repository layout
>
>
> Added files:
> branches/
> tags/
> trunk/
> vendor/
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
>
--
"I had a handle on life, but then it broke"
