- Ros-dev - ReactOS.org

EventLog documentation
by Saveliy Tretiakov 31 Jan '06

31 Jan '06

Hello. I've put some EventLog links on the wiki: http://www.reactos.org/wiki/index.php/EventLog

1 0

RE: [ros-dev] Undocumented APIs
by Murphy, Ged (Bolton) 31 Jan '06

31 Jan '06

D. Hazelton wrote: > Someone mentioned that regedit might be a piece of code which > is the only one > to use a function call... All modern windows releases ship > with two versions > of regedit, regedit.exe and regedt32.exe - and there have > been several > third-party replacements for regedit released. Win XP and above ship with a new regedit. Regedit.exe(win98 derivative) and regedt32.exe(crippled version for 2K) have both been dropped. Ged ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

1 0

GetGlyphOutline
by James Tabor 31 Jan '06

31 Jan '06

Hi, I finished a fast port of GetGlyphOutline from Wine. Not too bad, no crashes. Thanks, James

5 10

RE: Ros-dev Digest, Vol 17, Issue 64
by Lucio Diaz 31 Jan '06

31 Jan '06

Dont be silly, all of you, such audit will take at least half a year and reimplementing everything will just destroy the proyect. Use your heads, you are programmers, and you fear there is leaked code, if there is any their assembly it should be similar to the windows one, so be easy: compile reactos, dissasemble it. Then dissasemble windows. Write a tool that compares dissassembled code. And you have ONLY (and is still lots of work) to compare where there are enough coincidences betwen reactos assembly and windows assembly. Once you get to those spots you only have to check if there is a logical conclusion of a sole way of doing something (like clearing a stack) or a copied code. Why hope for reactos, Lucio Diaz. --------------------------------- LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

1 0

RE: [ros-dev] Bugzilla and Security Audit Documentation
by Murphy, Ged (Bolton) 30 Jan '06

30 Jan '06

M Bealby wrote: > Hey all, Hi Martin > 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? I think the best place for this would be bugzilla. You can group the full audit in one bug. > 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? I don't know what is happening with bugzilla at the moment. We've lost WaxDragon now :( He used to take care of bugzilla, and all other things related to testing. You don't want the job, do you ?? ;) > 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. When you submit it, I'll try to get it fixed straight away. I expect there to be quite a few fixes as I just threw this code together quickly to give us something to test with. ;) > Are we going to implement something like Peters /documentation/ patch? > If so I will put my security auditing notes in there too. I don't see any reason to store information which is going to be fixed. Bugzilla and SVN will take care of the history for us. However if there is general audit information in there, then I think is should be treated in the same manner as the rest and stored in the respective directory accordingly. Regards, Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

2 1

New Setup system
by David Hinz 30 Jan '06

30 Jan '06

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

11 20

RE: [ros-diffs] [martinf] 33: import the lean explorer branch into thenew repository
by Casper Hornstrup 30 Jan '06

30 Jan '06

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

1 0

NTOSKRNL Audit
by Ge van Geldorp 29 Jan '06

29 Jan '06

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

1 0

Bugzilla and Security Audit Documentation
by M Bealby 29 Jan '06

29 Jan '06

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

1 0

Pathcomments corrected
by Jack Bane 29 Jan '06

29 Jan '06

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

1 0

TLD documentation diff
by Peter Ward 29 Jan '06

29 Jan '06

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. +

1 0

Proposal for a new "Documentation Management" group
by Wierd_w 29 Jan '06

29 Jan '06

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

2 1

Samba 4.0TP (Second Post)
by Rick Langschultz 28 Jan '06

28 Jan '06

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.

1 0

ntdocs diff
by Jerry 28 Jan '06

28 Jan '06

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

2 1

How to audit.
by Jerry 28 Jan '06

28 Jan '06

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.

1 0

RE: [ros-diffs] [chorns] 11: Document rbuild
by Ge van Geldorp 28 Jan '06

28 Jan '06

> 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

2 1

what about stuff we share with Wine?
by Jonathan Wilson 28 Jan '06

28 Jan '06

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

2 1

Propose standards for the audit
by Steven Edwards 28 Jan '06

28 Jan '06

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

8 13

rev-doc diff.
by Jerry 28 Jan '06

28 Jan '06

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

2 2

Cleaned up skeleton?
by Jan Schiefer 28 Jan '06

28 Jan '06

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

3 3

Build system
by Martin Fuchs 28 Jan '06

28 Jan '06

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

5 5

RE: [ros-diffs] [frik85] 4: import reactos.org directory
by Casper Hornstrup 28 Jan '06

28 Jan '06

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

2 1

My thoughts
by Andrew "Silver Blade" Greenwood 28 Jan '06

28 Jan '06

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!

2 1

Re: [ros-diffs] [ion] 8: - Update directory change in rbuild/xml files too.
by Filip Navara 28 Jan '06

28 Jan '06

1 0

New repository?
by Reuben Perelman 28 Jan '06

28 Jan '06

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.

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev