I have already posted this in the NG but I was told that this would be more appropriate here.
One of my questions is how wine developers actualy develop their functions. I'm aware that some functions are (rather) easily determind just because of their name (i.e. CreateFile). Other functions can be derived from reading the documentation but there is quite a number of functions that arenot documented and some are not even mentioned anywhere (like functions in the rpcnt.dll). Now I wonder how you go about this. My approach would be to disassemble such functions and see how they work. Of course I know that in some countries this will be illegal while it is not in others. If I live in a country where this is legal would it still be a problem for the maintainer if I submit a function that is written based on the method I used to get the knowledge to write it? How do you circumvent that problem that you might infringe copyright as reverse engineering is usually prohibited by the licence where this licence is actually legally binding.
Another question is concerning the function CreateDispTypeInfo. I'd like to work on Hotline which uses this function. As I noticed, this function is stubbed but not implemented and the last time it was worked on was somewhere in 2000, so I'd like to know if somebody is working on this. If I start work on it, do I have to submit this info somewhere in order to avoid duplicate work?
Thanks.
On 2002.01.20 03:36 Gerhard W. Gruber wrote:
I have already posted this in the NG but I was told that this would be more appropriate here.
One of my questions is how wine developers actualy develop their functions. I'm aware that some functions are (rather) easily determind just because of their name (i.e. CreateFile). Other functions can be derived from reading the documentation but there is quite a number of functions that arenot documented and some are not even mentioned anywhere (like functions in the rpcnt.dll). Now I wonder how you go about this. My approach would be to disassemble such functions and see how they work. Of course I know that in some countries this will be illegal while it is not in others. If I live in a country where this is legal would it still be a problem for the maintainer if I submit a function that is written based on the method I used to get the knowledge to write it? How do you circumvent that problem that you might infringe copyright as reverse engineering is usually prohibited by the licence where this licence is actually legally binding.
Well, if the code you contribute could be considered a derived work of the code you disassembled then you'd have problems. But for instance if you disassembled for the purposes of figuring out how many arguments the function takes and what not but didn't actually directly write your code based on the disassembly, then you should be in the clear as far as that is concerned.
Now, as for the breaking of the license agreement on your software. That mostly concerns you as you are the person under the license, not the Wine project. So if you feel like you would get into legal trouble by even disassembling something to simply see what types of parameters it takes, then I would suggest that you didn't do it. However if you feel that you would not get into legal trouble, and assuming you don't create your implementation directly from the disassembly (i.e. you reimplement from scratch, but just use the disassembly to get some ideas of function parameters) then you should be very much in the clear, and so should the wine project.
Another question is concerning the function CreateDispTypeInfo. I'd like to work on Hotline which uses this function. As I noticed, this function is stubbed but not implemented and the last time it was worked on was somewhere in 2000, so I'd like to know if somebody is working on this. If I start work on it, do I have to submit this info somewhere in order to avoid duplicate work?
Hey man, if no one responds in this mailing list within a reasonable timeframe then probably no-one is working on it. Just have a go and if someone else beats you to it without saying anything you can always do a peer-review of the code and see if maybe something should be done different. Two pairs of eyes are better than one.
-Dave
-
David Elliott -
Gerhard W. Gruber