Tom Spear (Dustin Booker, Dustin Navea)
speeddymon at gmail.com
Tue Apr 25 18:10:29 CDT 2006
Paul Millar wrote:
> Hi Tom,
> On Tuesday 25 Apr 2006 19:05, Tom Spear wrote:
>> On 4/25/06, Paul Millar <paul at astro.gla.ac.uk> wrote:
>>> Yes, this looks to be amenable to a clean-room implementation. [...]
>> I don't see any reason why that couldn't work. We could combine that test
>> suite with users that use various pro-audio apps tests of said apps. For
>> example, some users prefer fruity loops over soundforge or acid, but we can
>> test all 3 against the implementation, modify (or initially write) the
>> tests to do the same things as these apps, and then build the
>> implementation based on the tests..
> Yes, one option is to use applications to do the testing. Another is to write
> discrete functional tests against each part of the API (c.f. the wine test
> framework). Both approaches have pros and cons.
> I was thinking more the wine test framework in mind. Assuming we use wine
> test, part of the "contaminated" student's job would be to write a set of
> tests (presumably with loads of todo_wine ok()s to begin with :). These
> tests would hopefully "cover" all the documented expected behaviour.
> As a bonus, writing the tests through wine test means it could be fairly
> easily tested what we (and presumably the SDK) thinks is correct behaviour
> against the various (close-source) implementations.
> The "clean" student would implement code and remove the "todo_wine" bit as she
>> Not to go off topic, but that might be a good method (now that I think
>> about it) to find out what various other apps do.. Sure it is the same as
>> making a testcase, but in this case, we are working backwards, which might
>> speed up patch production in some cases
>> If I am reading what you said above, you basically want to for example,
>> take fruity loops, figure out what it does when you do various things (by
>> tracing that app's execution), then using that trace, write our own code to
>> produce an _identical_ trace, and then use that code to make patches to
>> other areas of wine..
> At the risk of pointing out what may be obvious, what you describe here is
> (one element of) reverse engineering rather than a clean-room method.
> Yeah, you can do reverse engineering to figure out the *actual* behaviour,
> 1. its (probably) slower that doing a proper clean-room implementation,
> 2. you'd inherit any "bugs" from your applications,
> 3. you (probably) won't cover all the functionality. Some new app. might
> come along that wine won't support,
> On the plus side you see how applications are *actually* using the API (hence
> can support broken or illdefined behaviour, if the app needs it).
>> Am I off the mark here? If not that really could help out our release
>> cycle, and increase the number of bugs fixed per release.....
> Its horses for courses. Some of wine comes from applications not working,
> which is subsequently traced back to some undocumented behaviour in Windows.
> But, given the information available in the SDK, it would be a shame not to
> use it if we can.
Doing a trace as far as I understood it isn't really reverse
engineering, because you dont see the actual low-level or high level
code, you just see the result of what the code did.. Now if I am wrong,
then ya we definitely don't want to do that in our clean room
implementation, but it might be useful for the "contaminsted" student
that was mentioned in a previous email..
More information about the wine-devel