[patch] Garbage code in text string display

[Reece Dunn]

On 23/08/07, Guan Xin <guanx.bac at gmail.com> wrote:
> On 8/23/07, Juan Lang <juan.lang at 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