Hi Daniel,
My sense is that this would be legally still OK, even though it gets very close into that "not sure" grey area. Conceptually how is this tool different from e.g. http://www.rohitab.com/apimonitor or Wine +relay logs? It seems that making API monitor work on Wine (if it doesn't already) and comparing its output would get you the same things.
It does become a problem if you observe that winfoo.dll calls winbar.dll and replicate this behaviour on Wine. That's essentially the same as observing a native Windows library in Wine with Wine's logging tools.
I don't think comparing application runs on a large scale will be useful though. It may be useful to answer well-defined questions like "This game is passing incorrect parameters to IDirect3DVertexBuffer9::Lock. Does it to the same on Windows, or are we giving the game bad input?". Applications respond to differences in the environment (language, windows version, GPU, available hardware), so a behavioural difference is often not a problem.
Stefan
Am 2018-01-26 um 23:47 schrieb Daniel Santos:
Some time back I had investigated a concept for a tool to aid in discovering behavioral differences between Wine and Windows. I have most of the technological issues figured out -- it would be a bit of an undertaking, but can be developed iteratively so that it could begin to pay for its self fairly soon. However, I need advise on rather or not it would create tort.
Put simply, it would be a layer built into Wine that records win32/64 API calls and their results and another layer on Windows that does the same. The two results can then be analyzed to discover behavioral differences. Of course, this is a heavily over-simplified explanation as there are many gory details of how to make this work, perform acceptably, produce useful information, remove noise, etc., but could this produce a legal problem? I would hope to be able to use such a tool on a typical piece of commercial software with a typical EULA. To me, it doesn't seem differ much from what antivirus software does.
Thanks, Daniel