Ros-dev

ros-dev@reactos.org

5790 discussions

by David Hinz

Hey guys, at first I was shocked, when I read that you want to audit all code and will have to rewrite a lot of the old code, but then I realised, that this is a great chance for making improvements. Here's one of my ideas: We could create a completely new setup, that will have a gui (not really a new idea...). But the second thing would be to create something similar to debians apt and debconf. My idea was to create a new setup, that installs ReactOS in packets, that would look a bit like this: A compressed archive (maybe bzip) that contains a folder with all the files, that need to be installed, one file that contains informations like e.g. where to put the files (%SYSTEMROOT% or %WINDIR%...) and one script file that looks a bit like a batch file. Maybe we could add a file, that contains some questions and hints, that can be interpreted by different configuration utilities. That is, what is IN these archives, in addition to this the header of the file would contain uncompressed information about the dependencies, so that they are easier to read. All this would give us some big advantages. For example we would be able to create different distributions and repositories. Companies would be able to have a mirror of our repository and could additionally have their own repositories, whose files depend on ours. This would ease deployment in big companies and would be a big advantage compared to Microsoft, as everything happens completely unattended, even if you upgrade from ReactOS 1.0 to 3.0. I'm looking forward to read what you think about my idea. Greets, David Hinz

19 years, 10 months

RE: [ros-diffs] [martinf] 33: import the lean explorer branch into thenew repository

by Casper Hornstrup

If you want to use Subversion's merging abilities then you need to copy this from trunk. Casper

19 years, 10 months

NTOSKRNL Audit

by Ge van Geldorp

I've made a start with the audit of NTOSKRNL. The page http://www.reactos.org/wiki/index.php/Ntoskrnl_audit contains a list of all the public (either exported or syscall) routines of our ntoskrnl.exe, with a template to fill in the audit metrics which were proposed. I already checked the documentation status of all routines. GvG

19 years, 10 months

Bugzilla and Security Audit Documentation

by M Bealby

Hey all, I have finished my security audit of one of the pieces of code in the new svn repository! (/base/services/tcpsvcs/) In my audit notes I have listed the problems by simple filename:line, flaw, description. They are also dated. Is this the same sort of documentation you would like in svn and bugzilla too? On that note, what is happening with bugzilla? I seem to remember someone mentioning that someone was going to go through all the bug reports and close any that affected non-audited code. Is this correct? Should I submit my bug report anyway? I'll write something noticeable in the summary field so it is obvious it is to do with the security audit. Are we going to implement something like Peters /documentation/ patch? If so I will put my security auditing notes in there too. Cheers, Martin

19 years, 10 months

Pathcomments corrected

by Jack Bane

Corrected some "old-style" file path-comments JB

19 years, 10 months

TLD documentation diff

by Peter Ward

Index: documentation/README =================================================================== --- documentation/README (revision 0) +++ documentation/README (revision 0) @@ -0,0 +1,11 @@ +This is the documentation directory for the ReactOS project. + + +Directory Layout: + +api\ : Documentation for various APIs. +articles\ : Howto's, Articles and related documentation. +audit\ : Documentation about and gathered by the audit. +reverse.engineering\ : Clean-Room effort documentation. + : _Only_ human language and pseudo-code documentation is allowed here. +

19 years, 10 months

Proposal for a new "Documentation Management" group

by Wierd_w

Just an idea to kick around-- With the recent issues of reverse engineering, and our new-- extra stern-- IP policy, it appears that "cleanroom implementation" (US style) is going to be very strictly adhered to. This raises a few concernes to me, even though I dont develop code. 1) The developers that decide they will become(Stay) reverse-engineers are going to have a great deal on their plate allready. Not only will they have to decompile proprietary binaries, but they will also have to make documentation about the functions within those binaries. Asking them to manage the collective work of both themselves and other reverse engineers is asking too much. 2) Implementors are not allowed to have direct communication with reverse engineers, under US style CleanRoom implementation practices. So, I propose a new group classification, with the purposes of 1) Organizing, catalogueing, and possibly correcting (For spelling, and other grammaticals) the whitepaper documentation produced by the reverse engineers. 2) Offering the functional service of communicating with the reverse engineers any objections, or concerns the implementors might have. (EG, "XXXX XXXX does XXX XXX by YYYYY" is not sufficent to explain what is going on, can I get a better description?", the documentation manager group would contact the reverse engineer in question, and ask them to make an adendum to their documentation to address this issue, and would then contact the implementor after such addendum(s) have been completed, and filed.) This group would thus have responsibilities simmilar to "Editor", "Librarian", and "Secretary", which is why I propose the generic name "Documentation Manager(s)." If there is allready such a position/group, I withdraw the proposal. Otherwise, I dont see how we could really hope to pull this off without dedicated individuals on this task. (PS, having "non-Coders" on this taskforce would probably alleviate any allegations of contamination between reverse engineers and Implemntors, in that it is unlikely that the secretary in question would understand a very technical request to begin with, and thus be unable to pass on any such complicated requests in their duties as secretary. It would also give some really strong enthusiasts something to do-- All you need are clerical and communication skills.) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

19 years, 10 months

Samba 4.0TP (Second Post)

by Rick Langschultz

Has anyone checked out the Samba 4.0 Tech Preview? I think the NTVFS folder includes code that allows another FS to act like NTFS. But take a look and tell me if integration to ReactOS would be a good idea.

19 years, 10 months

ntdocs diff

by Jerry

Please ignore my last diff; this is an improved version. This diff sets up a directory (ntdocs) where documention and test cases and be put. I sugest that the tree for this dir should mirror the actual code base for ease of use. Thanks. Index: ntdocs/readme.txt =================================================================== --- ntdocs/readme.txt (revision 0) +++ ntdocs/readme.txt (revision 0) @@ -0,0 +1,6 @@ +This directory contains the documentation for Reactos (test cases and the like). Please do NOT put actual code here. +Just enough to implement it. Only human lanuage and puedo-code is allowed here. If you reversed engeneered, it please keep the policy and DO NOT implement it. + +The tree layout for the docs should mirror that of the actual code tree for ease of use. + +Thanks. \ No newline at end of file

19 years, 10 months

How to audit.

by Jerry

I think we need to be more organized in this endeavor. We need to decided who will look at chuck of code, so that the process goes faster. I suggest that we pair up into two person teems whose responsibility is to decide if a certain group of code it dirty or not. These teems will then look at their area of code systematicly, deciding if part or alll of the code they come across is dirty. All the clean code will then be put into the audited trunk, then the stripped stub of the functions that were dirty.

19 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev