On 8/24/07, Reece Dunn <[EMAIL PROTECTED]> 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