On Tue, Nov 13, 2018 at 1:35 PM Nikolay Sivov nsivov@codeweavers.com wrote:
On 11/13/18 1:35 PM, Gabriel Ivăncescu wrote:
Signed-off-by: Gabriel Ivăncescu gabrielopcode@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.