On Thu, 13 Nov 2008, Juan Lang wrote: > > Any feedback on the spec file or the debug trace? > > I'm afraid I don't know what substantive difference there is between > looking at one small portion of the disassembly (to verify a function > is being called) and learning something more substantial. There are > certain kinds of reverse engineering that are allowed, but looking at > disassembly is not.
And now that I know that, I certainly won't be doing it again. > I don't think this is going to go in, sorry. Well, I still have an application that won't run under wine because this function is not implemented. So assuming *this* patch doesn't get in, what can I do to help get *a* patch in that implements this function? I can blow away my sandbox and start from scratch, but I suspect you would find that insufficient. Maybe I should find a hypnotist to make me forget what I saw in the debugger :) Would it be acceptable for me to write up a description of what the function needs to do, so that someone else can do a clean-room implementation? It would probably take a reasonably experienced C/COM developer all of about 5 minutes, since this function is really just a wrapper of an already-implemented function. Is there anyone out there who would volunteer to do it if I were to write a description of the function? If I provided a patch to dlls/oleaut32/tests/olepicture.c adding tests that verify the behaviors of the functions, would that be accepted? Or is writing tests for functions you've seen the disassembly for also prohibited? I realize now that I've made a mistake by looking at the function in the debugger, but hopefully there is still a way I can help get this function implemented. Thanks, Jeremy