On 8/23/07, Juan Lang juan.lang@gmail.com wrote:
You may generally post source to wine-devel if it's short and to the point. Please don't post a binary.
Acturally, this bug is obvious as I have pointed it out. No source is needed for demonstration. Also I always programmed with Borland's AFX when I used Windows. So my source is unlikely to compile under WINE or MSVC. Recently I have no Windows machine and cannot learn Windows API programming to write those tests.
Right to the first point, which is why we write tests that pass on Windows, and fix Wine to match the tests. This obviates the need to look at Windows source.
You must be mistaken. Tests that fail when WINE is not patched and pass when patched do not prove correctness of the midification. They only increase the possibility of its correctness. I am sorry I never learnt computer science and misunderstood your requisition.
Here is an analogy to show what you are doing: in order to find out how to turn off the light, a computer scientist tried to place a piece of wire into the outlet and made a short-circuit. He succeeded. His `test case' never failed as far as he lived. The computer scientist electrocuted himself.
On 23/08/07, Guan Xin guanx.bac@gmail.com wrote:
On 8/23/07, Juan Lang juan.lang@gmail.com wrote:
You may generally post source to wine-devel if it's short and to the point. Please don't post a binary.
Acturally, this bug is obvious as I have pointed it out. No source is needed for demonstration. Also I always programmed with Borland's AFX when I used Windows. So my source is unlikely to compile under WINE or MSVC. Recently I have no Windows machine and cannot learn Windows API programming to write those tests.
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.
Right to the first point, which is why we write tests that pass on Windows, and fix Wine to match the tests. This obviates the need to look at Windows source.
You must be mistaken. Tests that fail when WINE is not patched and pass when patched do not prove correctness of the midification. They only increase the possibility of its correctness. I am sorry I never learnt computer science and misunderstood your requisition.
As well as being run on Wine, they are run on different Windows versions as well, to verify them on all platforms.
Here is an analogy to show what you are doing: in order to find out how to turn off the light, a computer scientist tried to place a piece of wire into the outlet and made a short-circuit. He succeeded. His `test case' never failed as far as he lived. The computer scientist electrocuted himself.
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.
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.
- Reece
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
-
Guan Xin -
Reece Dunn