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!
From my viewpoint, right where I'm sitting now - Microsoft Publications
published a book called "Inside Windows NT" which has metamorphosed into "Inside Windows 2000" and so on. Lou Perazzoli wrote the Foreword, giving the official Microsoft seal of approval to the contents of the book. David Solomon goes into detail about _how_ _to_ _reverse-engineer_ "EXPERIMENT: Generating a Crash Dump to Use with the Kernel Debugger", pg 23; and Microsoft made no complaint.
As far as I can see, Microsoft did not specify the uses one could make of reverse-engineering the WinNT kernel in this book. It assumed that there could only be one use. It assumed people would not be reverse-engineering the WinNT kernel to find out how it did things in order to do it better, by writing a WinNT-compatible, WinNT-class kernel.
So it cannot complain; it has no right, no basis to complain that people may reverse-engineer the WinNT kernel - because they have even published tools to do exactly that, and published instructions on how to use them for best effect - "Table 1-3 shows a complete list of all the tools used in this book and where they come from." pp17 - 18
And again, there's a book on the Native NT API, and Microsoft has made no complaint about that, in spite of it being an obvious reverse-engineering effort. Ditto Russinovich's website/s.
Lawyers call this sort of situation "Preclusion" and "Estoppel".
But in order to be safe, I think the best thing to do would be if the reverse-engineerer wrote a detailed description of the function/s he's reverse-engineered, all relevant details, etc, then published it in a section of the website set aside specifically for this - ie, open only to people with writable svn accounts and the inevitable document-writer. And after the project reaches late stage Beta - 0.8.x perhaps - it becomes openly published, and hopefully the document-writer will have turned it into an O'Reilly-ready book.
Just my 0.02c - stagflation, of course! ;)
Wesley Parish
On Sat, 28 Jan 2006 04:47, Andrew "Silver Blade" Greenwood wrote:
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!
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Andrew "Silver Blade" Greenwood -
Wesley Parish