Ros-dev

ros-dev@reactos.org

5790 discussions

RE: [ros-diffs] [chorns] 11: Document rbuild

by Ge van Geldorp

> From: chorns(a)svn.reactos.org > > Document rbuild > Property changes on: trunk/reactos/tools/rbuild > Name: svn:doc It seems your brain is pre-wired to type "svn:..." after "propset" :-) GvG

19 years, 10 months

what about stuff we share with Wine?

by Jonathan Wilson

Are we going to have to audit that too? Is there a risk that Wine might contain compromised code somehow?

19 years, 10 months

Propose standards for the audit

by Steven Edwards

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

19 years, 10 months

rev-doc diff.

by Jerry

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

19 years, 10 months

Cleaned up skeleton?

by Jan Schiefer

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

19 years, 10 months

Build system

by Martin Fuchs

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

19 years, 10 months

RE: [ros-diffs] [frik85] 4: import reactos.org directory

by Casper Hornstrup

This is wrong. Bugzilla is 3rd party software and needs to go to /vendor/bugzilla/current. Casper

19 years, 10 months

My thoughts

by Andrew "Silver Blade" Greenwood

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!

19 years, 10 months

Re: [ros-diffs] [ion] 8: - Update directory change in rbuild/xml files too.

by Filip Navara

19 years, 10 months

New repository?

by Reuben Perelman

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.

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