[PATCH v4 3/7] comctl32/listbox: Use ULONG_PTR instead of DWORD when retrieving text without HAS_STRINGS

[Gabriel Ivăncescu]

On Tue, Nov 13, 2018 at 1:35 PM Nikolay Sivov <nsivov at codeweavers.com> wrote:
>
> On 11/13/18 1:35 PM, Gabriel Ivăncescu wrote:
>
> > Signed-off-by: Gabriel Ivăncescu <gabrielopcode at gmail.com>
> > ---
> >
> > The test has been updated to deal with the bug. This is clearly broken Windows
> > behavior, because the same 32-bit app returns a different size depending on
> > whether it's ran under WOW64 or natively 32-bit, and only with LB_GETTEXTLEN,
> > which makes no sense at all. So IMO we can choose which one to return here,
> > and size of a pointer simply makes more sense.
>
> I don't think broken() is justified in this case. It's consistent across
> Windows versions and it's clear how it's triggered.
>
> To some level it doesn't have to make sense and we might consider making
> it "right", but for now I agree, let's keep a todo
> while returning consistent data length until we find something that
> depends on it.

There are many WOW64-only bugs (I mean, known by Microsoft), I think
this classifies as one of them. Think about it for a minute: first,
the behavior between the *same* 32-bit app is different on WOW64 and
native 32-bit version of Windows. And we're talking about something
like the length of a buffer here, not some cosmetic change.

Secondly, even with WOW64 it returns only the size of a pointer (4
bytes) in LB_GETTEXT, but LB_GETTEXTLEN says the length of the same
"text" is 8? That makes no sense to me. It's inconsistent.

If you feel very strongly about it, I will change it to a todo, but I
honestly think this is clearly broken.