[patch] Garbage code in text string display

Guan Xin guanx.bac at gmail.com
Mon Aug 27 02:23:41 CDT 2007


On 8/24/07, Reece Dunn <msclrhd at 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



More information about the wine-devel mailing list