Christian Gmeiner wrote:
Partially implement SetupDiGetClassDevsExA. This patch bases on reactos setupapi.dll.
Don't be suprised if your patch isn't accepted. ReactOS is considered a dirty reverse engineering project by many, and Alexandre has rejected patches using their code before.
The fact that some developers work both on tinykrnl (a self-admitted 'dirty' reverse engineering effort) and ReactOS at the same time should be enough to show you that they're walking close to, or maybe over the fine line.
Please don't post ReactOS code to wine-patches again.
Mike
Mike McCormack wrote:
Christian Gmeiner wrote:
Partially implement SetupDiGetClassDevsExA. This patch bases on reactos setupapi.dll.
Don't be suprised if your patch isn't accepted. ReactOS is considered a dirty reverse engineering project by many, and Alexandre has rejected patches using their code before.
I thought they started auditing their code and removing any "dirty" parts? And according to their website this process is nearly done.
btw. using their code as documentation to implement something on wine should be safe nevertheless, shouldn't it?
The fact that some developers work both on tinykrnl (a self-admitted 'dirty' reverse engineering effort) and ReactOS at the same time should be enough to show you that they're walking close to, or maybe over the fine line.
Please don't post ReactOS code to wine-patches again.
hm I thought direct code sharing wasn't even possible before because of the different licenses(GPL<->LGPL)?
"Peter Beutner" p.beutner@gmx.net wrote:
Don't be suprised if your patch isn't accepted. ReactOS is considered a dirty reverse engineering project by many, and Alexandre has rejected patches using their code before.
I thought they started auditing their code and removing any "dirty" parts?
At least for me their "auditing" mostly looks like a way to show to the outside world that they are considering to avoid dirty practices when they actually didn't change anything except public claims.
And according to their website this process is nearly done.
What they want people should think about their project has nothing to do with real state of affairs.
btw. using their code as documentation to implement something on wine should be safe nevertheless, shouldn't it?
Not really IMO, nobody can hide their history, and all the things about attempts to compile stolen Windows sources and disassembling practices.
Peter Beutner wrote:
I thought they started auditing their code and removing any "dirty" parts? And according to their website this process is nearly done.
Unfortunately, the fallout of their audit process has been that many trusted developers left the project.
For me, the main problem is that there are ReactOS developers who think that examining Windows assembly to write ReactOS code is a proper way to do things.
btw. using their code as documentation to implement something on wine should be safe nevertheless, shouldn't it?
I'd avoid their code if I were you.
hm I thought direct code sharing wasn't even possible before because of the different licenses(GPL<->LGPL)?
If the same people "came up with" the code in question, the license isn't relevant.
IMO, the only legitimate thing to use would be their test cases, and there's only a few of those as far as I can tell.
Mike
Mike McCormack wrote:
Peter Beutner wrote:
I thought they started auditing their code and removing any "dirty" parts? And according to their website this process is nearly done.
Unfortunately, the fallout of their audit process has been that many trusted developers left the project.
For me, the main problem is that there are ReactOS developers who think that examining Windows assembly to write ReactOS code is a proper way to do things.
I think the problem is that the way you describe is totally legal in most countries. In fact, afaik it is only in the USA where you have this explicit distinction between clean("chinese wall") and "dirty" reverse engineering. Which reminds me of a similiar thread on lkml about which country's laws actually applies here. hmm ...
btw. using their code as documentation to implement something on wine should be safe nevertheless, shouldn't it?
I'd avoid their code if I were you.
ok, seems to be the easiest/cleanest solution ;)
Peter Beutner wrote:
For me, the main problem is that there are ReactOS developers who think that examining Windows assembly to write ReactOS code is a proper way to do things.
I think the problem is that the way you describe is totally legal in most countries. In fact, afaik it is only in the USA where you have this explicit distinction between clean("chinese wall") and "dirty" reverse engineering. Which reminds me of a similiar thread on lkml about which country's laws actually applies
This is not simply a problem of what is legal and not in different countries.
We don't want to be associated project that is perceived to be pushing the edge of what's legally (or even socially) acceptable. Doing so would encourage FUD about Wine and that's a good way to lose developers and users.
Furthermore, by examining and recoding somebody else's work, you neither gain a good understanding of how it works, nor lay the foundation for somebody else to fix it without repeating what you did.
Using test cases to determine the behaviour of Windows provides a way to verify both the code that's written today, and code that will be written a year later. It's not just legally better, it's easier to do, easier for others to understand, and gives us a way to verify our code.
Mike
* On Sat, 10 Jun 2006, Mike McCormack wrote:
- Peter Beutner wrote:
I think the problem is that the way you describe is totally legal in most countries. In fact, afaik it is only in the USA where you have this explicit distinction between clean("chinese wall") and "dirty" reverse engineering.
This is not simply a problem of what is legal and not in different countries.
We don't want to be associated project that is perceived to be pushing the edge of what's legally (or even socially) acceptable. Doing so would encourage FUD about Wine and that's a good way to lose developers and users.
Mike, and how would you describe API monitoring method of understanding how the stuff works? Does its use for finding misbehaved functions make Wine look like it pushes the edge?
Using test cases to determine the behaviour of Windows provides a way to verify both the code that's written today, and code that will be written a year later. It's not just legally better, it's easier to do, easier for others to understand, and gives us a way to verify our code.
Yes, but how would you write a test for a badly implemented function, when you don't know its name or even name of a DLL it resides in?
Saulius Krasuckas wrote:
Mike, and how would you describe API monitoring method of understanding how the stuff works?
You mean using +relay? IMO, that's a legitimate way of understanding how things work.
Does its use for finding misbehaved functions make Wine look like it pushes the edge?
If it's done using black box techniques, IMO, it's legitimate.
Finding out how an public _interface_ behaves for various inputs and outputs is legitimate, IMO.
Examining piece of assembly to determine _implementation_ is not, IMO.
This is assuming that _interfaces_ are not copyright-able, whereas _implementations_ are.
Yes, but how would you write a test for a badly implemented function, when you don't know its name or even name of a DLL it resides in?
If there's no program that uses that function, then it's not necessary that for Wine to implement it, so it doesn't matter. If there's a program that uses it, then we can get a sample input.
Wine is concerned with interoperability with programs written for the Win32 API. We don't care how other implementations of the Win32 API work, we only care what is required for programs to work.
I am *not* giving legal advice. This is my interpretation of how interoperability with Windows programs should be legitimately achieved, and what standards Wine contributors should live up to.
Mike
* On Mon, 12 Jun 2006, Mike McCormack wrote:
- Saulius Krasuckas wrote:
Mike, and how would you describe API monitoring method of understanding how the stuff works?
You mean using +relay? IMO, that's a legitimate way of understanding how things work.
Not exactly. What about strace.exe or stracent.exe under real windows?
If it's done using black box techniques, IMO, it's legitimate.
Finding out how an public _interface_ behaves for various inputs and outputs is legitimate, IMO.
Examining piece of assembly to determine _implementation_ is not, IMO.
Ok, let go further than my primary question.
And what if interface is blackboxed? Would you consider analysis of a stack and CPU registers during a breakpoint at the very beginning of API call legitimate? In real windows, of course. That's about some data passing through an interface, not about some code assembly.
This is assuming that _interfaces_ are not copyright-able, whereas _implementations_ are.
Of course. But when interfaces gets hidden, we start walking on the low-level line where interface details border implementation details. No?
If there's a program that uses it, then we can get a sample input.
Of course I spoke about real programs. Example was Diablo (v1), where I just hadn't enough skills to understand what here doesn't work. Later I opened a bug report (2 years ago). Now I think tracing the game in windows would help me.
I am *not* giving legal advice. This is my interpretation of how interoperability with Windows programs should be legitimately achieved, and what standards Wine contributors should live up to.
That's fine, Mike. I understand that disc^H^H^H^Hpart pretty well, I hope :)
Saulius Krasuckas wrote:
And what if interface is blackboxed?
I don't know what a "blackboxed interface" is. If you could name the interface you're talking about it would be easier to understand what you mean.
Mike
* On Mon, 12 Jun 2006, Mike McCormack wrote:
- Saulius Krasuckas wrote:
And what if interface is blackboxed?
I don't know what a "blackboxed interface" is. If you could name the interface you're talking about it would be easier to understand what you mean.
I remember that last one was GetUName!getuname:
[2] http://www.winehq.org/pipermail/wine-devel/2006-June/048500.html
"Saulius Krasuckas" saulius2@ar.fi.lt wrote:
- On Mon, 12 Jun 2006, Mike McCormack wrote:
- Saulius Krasuckas wrote:
And what if interface is blackboxed?
I don't know what a "blackboxed interface" is. If you could name the interface you're talking about it would be easier to understand what you mean.
I remember that last one was GetUName!getuname:
[2] http://www.winehq.org/pipermail/wine-devel/2006-June/048500.html
That one doesn't count (there were enough explanations why). Another one?
* On Tue, 13 Jun 2006, Dmitry Timoshkov wrote:
- "Saulius Krasuckas" saulius2@ar.fi.lt wrote:
- On Mon, 12 Jun 2006, Mike McCormack wrote:
- Saulius Krasuckas wrote:
And what if interface is blackboxed?
I don't know what a "blackboxed interface" is. If you could name the interface you're talking about it would be easier to understand what you mean.
I remember that last one was GetUName!getuname: [2] http://www.winehq.org/pipermail/wine-devel/2006-June/048500.html
That one doesn't count (there were enough explanations why). Another one?
Well, next example hasn't forced us to wait long for it. It's Direct3DShaderValidatorCreate9!d3d9 :
[3] http://www.winehq.org/pipermail/wine-patches/2006-June/027601.html
"Saulius Krasuckas" saulius2@ar.fi.lt wrote:
Well, next example hasn't forced us to wait long for it. It's Direct3DShaderValidatorCreate9!d3d9 :
[3] http://www.winehq.org/pipermail/wine-patches/2006-June/027601.html
Just replied to that e-mail. So that one doesn't count either. My guess is the author of the "patch" is using a load of native d3d dlls.
Saulius Krasuckas wrote:
Well, next example hasn't forced us to wait long for it. It's Direct3DShaderValidatorCreate9!d3d9 :
Do you really need to look at assembly to figure out that you can just return FALSE/0/NULL and make the program or dll that's calling this function happy?
If that doesn't make it happy, you could always write a test program that calls the function and prints out the return value. That is not hard either.
You want to tell me that it's easier to try decipher a bunch of asm that it is to write a 10 line test program??
I fail to see anything different here.
Mike
* On Fri, 16 Jun 2006, Mike McCormack wrote:
- Saulius Krasuckas wrote:
Well, next example hasn't forced us to wait long for it. It's Direct3DShaderValidatorCreate9!d3d9 :
(I'm sorry for swapping both parts of a function name each with other;)
Do you really need to look at assembly to figure out that you can just return FALSE/0/NULL and make the program or dll that's calling this function happy?
No, I don't. I was speaking about passing unknown count of parameters to a function.
If that doesn't make it happy, you could always write a test program that calls the function and prints out the return value. That is not hard either.
If I know what to pass to the fn, I can, of course.
You want to tell me that it's easier to try decipher a bunch of asm that it is to write a 10 line test program??
No, I am all just about the CPU registers and stack content, not an asm.
To be honest, Mike, at start I was trying to see, whether my idea of API monitoring [4] would be acceptable for wine-developers (esp. starters). Now I want to correct myself--I was talking about +relay debug only.
But at some time this discussion got slightly different point, which still has some relation to my idea.
Why is all this? I am trying start my master thesis and have a thought: can't I link my favourite project (Wine) with one which has something to do with computer hardware--with BOCHS? (as I study electronics) [5]
Here, we are urged to create mathematical model for every research object. I thought well, what can present a norma, an abstract system to measure difference between real WinAPI and WineAPI? Maybe count of lines of a unified diff of relay traces would help?
And if BOCHS starts supporting adiabatic machine simulation once, we get nice ability to rewind process execution back in time. No?
Plus I remembered I did always want to have a nice, non-intrusive WinAPI monitoring.
So was the decision made to ask wine-devs about API monitoring and its usefullness :)
Thank you for reading this.
[4] http://winehq.org/pipermail/wine-devel/2006-March/045907.html [5] http://medeine.vtu.lt/programos/programa.jsp?fak=5&prog=7542217&sid=...
"Saulius Krasuckas" saulius2@ar.fi.lt wrote:
Using test cases to determine the behaviour of Windows provides a way to verify both the code that's written today, and code that will be written a year later. It's not just legally better, it's easier to do, easier for others to understand, and gives us a way to verify our code.
Yes, but how would you write a test for a badly implemented function, when you don't know its name or even name of a DLL it resides in?
Then by what means do you know that the API is misbehaving?
* On Mon, 12 Jun 2006, Dmitry Timoshkov wrote:
- "Saulius Krasuckas" saulius2@ar.fi.lt wrote:
Yes, but how would you write a test for a badly implemented function, when you don't know its name or even name of a DLL it resides in?
Then by what means do you know that the API is misbehaving?
By the fact of my special app [*] not working in Wine ;-)
"Saulius Krasuckas" saulius2@ar.fi.lt wrote:
Yes, but how would you write a test for a badly implemented function, when you don't know its name or even name of a DLL it resides in?
Then by what means do you know that the API is misbehaving?
By the fact of my special app [*] not working in Wine ;-)
I see nothing there which shows that a test case couldn't be written. Moreover, there is nothing there described in the 1st paragraph above.
* On Mon, 12 Jun 2006, Dmitry Timoshkov wrote:
- "Saulius Krasuckas" saulius2@ar.fi.lt wrote:
Yes, but how would you write a test for a badly implemented function, when you don't know its name or even name of a DLL it resides in?
Then by what means do you know that the API is misbehaving?
By the fact of my special app [*] not working in Wine ;-)
I see nothing there which shows that a test case couldn't be written.
Would you been seeing this similar way if Vincent P. hadn't made his discovered? And what if this discovery was made by reverse engineering the code?
Moreover, there is nothing there described in the 1st paragraph above.
Lets say we have got only 22 numbers of responces in the report [*]. What would you suggest me to do? To annoy everyone on the list during 2 years by asking for a tutorial on how to debug dx game which draws black menu? ;-)
"Saulius Krasuckas" saulius2@ar.fi.lt wrote:
What would you suggest me to do? To annoy everyone on the list during 2 years by asking for a tutorial on how to debug dx game which draws black menu? ;-)
Make yourself an expert in the area you are trying to improve. Read MSDN, books, find code samples on the net, write the tests on your own.
* On Tue, 13 Jun 2006, Dmitry Timoshkov wrote:
- "Saulius Krasuckas" saulius2@ar.fi.lt wrote:
What would you suggest me to do? To annoy everyone on the list during 2 years by asking for a tutorial on how to debug dx game which draws black menu? ;-)
Make yourself an expert in the area you are trying to improve. Read MSDN, books, find code samples on the net, write the tests on your own.
Sometimes comparing traces is easier than buying a book, for which I have no money or is more ethical than reading a book, which perhaps was written by a reverse engineer about his knowlegde, don't you think so?
But, Dmitry, you haven't answered the question about the legitimity of the analysis from the mentioned bug [*] yet. I state it was collected by reverse engineering. Should I erase my memory or ask Tony to delete appropriate DB records from the bugzilla? ;-)
"Saulius Krasuckas" saulius2@ar.fi.lt wrote:
- "Saulius Krasuckas" saulius2@ar.fi.lt wrote:
What would you suggest me to do? To annoy everyone on the list during 2 years by asking for a tutorial on how to debug dx game which draws black menu? ;-)
Make yourself an expert in the area you are trying to improve. Read MSDN, books, find code samples on the net, write the tests on your own.
Sometimes comparing traces is easier than buying a book,
IMO you'd spend that 2 years much more productively by learning how the things work instead of trying to understand gibberish of the traces. Perhaps you would even become a high quality specialist in that area and could star earning more money for your life.
for which I have no money
Do the libraries exist in your area?
or is more ethical than reading a book, which perhaps was written by a reverse engineer about his knowlegde, don't you think so?
Oh year, speculating about the source of the book which you don't want to read is much more productive than actually learning something.
But, Dmitry, you haven't answered the question about the legitimity of the analysis from the mentioned bug [*] yet. I state it was collected by reverse engineering. Should I erase my memory or ask Tony to delete appropriate DB records from the bugzilla? ;-)
Are you talking about http://bugs.winehq.org/show_bug.cgi?id=2081 ?
* On Tue, 13 Jun 2006, Dmitry Timoshkov wrote:
- "Saulius Krasuckas" saulius2@ar.fi.lt wrote:
Make yourself an expert in the area you are trying to improve. Read MSDN, books, find code samples on the net, write the tests on your own.
Perhaps you would even become a high quality specialist in that area and could star earning more money for your life.
That's very lose dependency. It is required, yes, but not sufficient. Besides, priorities in my life is to avoid money as much as I can. Does this practically discourage me from helping Wine? ;-)
Oh year, speculating about the source of the book which you don't want to read is much more productive than actually learning something.
Are you sure I haven't read "Windows 95 Secrets" by Matt Pietrek? BTW, it was printed in your native language ;-)
[switching to private communication mode]
But, Dmitry, you haven't answered the question about the legitimity of the analysis from the mentioned bug [*] yet. I state it was collected by reverse engineering. Should I erase my memory or ask Tony to delete appropriate DB records from the bugzilla? ;-)
Are you talking about http://bugs.winehq.org/show_bug.cgi?id=2081 ?
Yes.
Dmitry Timoshkov wrote:
"Saulius Krasuckas" saulius2@ar.fi.lt wrote:
What would you suggest me to do?
Make yourself an expert in the area you are trying to improve.
I try to do that for almost a year now for winspool / Printing.
Read MSDN,
Done for many Functions. MSDN is not complete and not Error-Free.
books,
Many of them. Do not forget the Oldies (Oldies are goldies!): They do not depend on MFC / DotNet / C#
As an Example, my old win3.1 - Book has Descriptions for every Entry in "win.ini" / "system.ini"
find code samples on the net,
Most samples still does not work.
write the tests on your own.
I started with an app, that call the winspool.drv - API by the Commandline. Now, i do most extensions directly for the Testsuite.
--- Peter Beutner p.beutner@gmx.net wrote:
Mike McCormack wrote:
Christian Gmeiner wrote:
Partially implement SetupDiGetClassDevsExA. This
patch bases on
reactos setupapi.dll.
Don't be suprised if your patch isn't accepted.
ReactOS is considered a
dirty reverse engineering project by many, and
Alexandre has rejected
patches using their code before.
I thought they started auditing their code and removing any "dirty" parts? And according to their website this process is nearly done.
btw. using their code as documentation to implement something on wine should be safe nevertheless, shouldn't it?
The fact that some developers work both on
tinykrnl (a self-admitted
'dirty' reverse engineering effort) and ReactOS at
the same time should
be enough to show you that they're walking close
to, or maybe over the
fine line.
Please don't post ReactOS code to wine-patches
again. hm I thought direct code sharing wasn't even possible before because of the different licenses(GPL<->LGPL)?
Only the ReactOS kernel is GPL, other parts have other licences. And they took SETUPAPI from us so it's still licenced under the LGPL.
Am I to understand that if I want SetupDiGetClassDevsExW() and some other APIs I need for the still image system, I need to write them without even looking at the ReactOS code? I think that's unfair, the ReactOS SETUPAPI doesn't look reverse-engineered, everything in there conforms to the MSDN documentation and it's too incomplete to be reverse-engineered. Making such harsh judgements about one API (which they derived from wine and changed a little) just because of the bad reputation of some other parts of ReactOS is wrong, IMO.
So what's the story, are you accepting any ReactOS-derived patches for dlls/setupapi/devinst.c, or do I need to start writing my own?
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Damjan Jovanovic dj015@yahoo.com writes:
So what's the story, are you accepting any ReactOS-derived patches for dlls/setupapi/devinst.c, or do I need to start writing my own?
No ReactOS-derived code will be accepted in Wine at this point.
-
Alexandre Julliard -
Damjan Jovanovic -
Detlef Riekenberg -
Dmitry Timoshkov -
Mike McCormack -
Peter Beutner -
Saulius Krasuckas