On 8/24/07, Reece Dunn msclrhd@googlemail.com wrote:
You don't need to have a Windows machine to write the tests. You can write them and build them through the Wine libraries. The reason for building them on Windows is so that you can verify them against Windows, but you could always post the tests for other developers to try.
That's fine! I'll learn some Windows API programming when I have time. Maybe in my next life. I used to program with C++Builder and was very familiar with that tool. Now that I left my previous affiliation and have little opportunity to access Windows.
As well as being run on Wine, they are run on different Windows versions as well, to verify them on all platforms.
No use. You cannot exhaust all possibilities.
A better analogy would be that you have a light switch and a light bulb. The light switch is your input and the light bulb is the output. Everything else is unknown (a black box). You don't know how it works.
You could open the box up and look inside (the equivalent of looking at the Windows source), but Wine can't do that. Also, if you modify the Wine code to improve it, you may break something. This would be like making a short circuit in your example above: the light no longer works in your replica (i.e. Wine), so any tests will fail on that.
What you can do instead is say that when the light switch is on the 'up' position, the light bulb is on and when the switch is on the 'down' position, the light bulb is off.
Now say you have two rows of 4 switches and a row of 4 lights, aligned with each other. What is the behaviour of this system? The only way to find out (without looking inside) is to devise a set of tests. This way, you can find out what logic the system is using. For example, if the system is behaving like a binary adder, you can deduce that from the tests.
That sounds effective if every light is controlled ONLY by the switches nearest to itself, since there are acturally infinite such switches.
The tests in Wine are designed to pass on Windows (and should, in theory, pass cleanly on that platform). The implementation of Wine is then written to pass those tests, therefore matching the _behaviour_ of Windows.
Specifically, a test would need to be created that highlights the MBCS program issue you identified, and verify that on Window it is returning DEFAULT_CHARSET. When this is run on Windows, it will pass, because it is testing that what is returned is DEFAULT_CHARSET. However, when this is run on an unpatched Wine, it will fail because Wine is returning ANSI_CHARSET. Now, running the tests on a patched version of Wine will cause that test to pass, matching the behaviour on Windows.
I know what you mean. That's fine and clear. I lost my engineer's brain three years before since I changed my profession. No I recalled that technical proofs should never be strict.
Best wishes and hope you to progress!
Xin