paul at astro.gla.ac.uk
Tue Apr 25 14:56:14 CDT 2006
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060425/ec7c091d/attachment.pgp
More information about the wine-devel