https://bugs.winehq.org/show_bug.cgi?id=47762
Bug ID: 47762 Summary: LoadStringA fails instead of returning const pointer to string if buffer length is zero Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: tsmx@tut.by Distribution: ---
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-loadst...
According to MSDN doc, LoadStringA should be able to return const pointer without using allocated buffer if the buffer size is set to zero.
Here we see that Wine just returns -1 in that case:
https://source.winehq.org/git/wine.git/blob/refs/heads/master:/dlls/user32/r...
Since there is something that looks legit in the LoadStringW just above, it shouldn't be too hard to fix, amirite?
https://bugs.winehq.org/show_bug.cgi?id=47762
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
--- Comment #1 from Zhiyi Zhang zzhang@codeweavers.com --- Some tests would be required to fix this. For example, what happens when Unicode/ASCII string resources are loaded by LoadStringA/W?
https://bugs.winehq.org/show_bug.cgi?id=47762
--- Comment #2 from Alexandre Julliard julliard@winehq.org --- String resources are stored in Unicode, so only LoadStringW is able to return a direct pointer. That's how it works on Windows. Is there an actual app that needs a different behavior?
https://bugs.winehq.org/show_bug.cgi?id=47762
--- Comment #3 from Stanislav tsmx@tut.by --- (In reply to Alexandre Julliard from comment #2)
String resources are stored in Unicode, so only LoadStringW is able to return a direct pointer. That's how it works on Windows.
Ok, now I see. There is some kind of fixed-length Unicode and not UTF-8 used in the compiled resources so we cannot just take ANSI-only Unicode string and say it's a valid ASCII one.
But then how does Windows do it? Converting string to ASCII in some kind of implicit temporary buffer? Telling resource compiler that it should pack string data in non-Unicode mode if we will be using A-suffixed functions?
I mean, MS doc says black on white that LoadStringA should somehow work with zero buflen, so this one probably shouldn't be completely ignored even if I'm misunderstanding something.
Is there an actual app that needs a different behavior?
No, not really. In fact, I've been just making one as my uni assignment and stumbled upon this issue.
https://bugs.winehq.org/show_bug.cgi?id=47762
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Alexandre Julliard julliard@winehq.org --- I see no evidence that Windows does this, and our existing tests don't show it either. Unless you can write a test case that shows differently, I'd just assume that MSDN is incorrect, it happens fairly often.
https://bugs.winehq.org/show_bug.cgi?id=47762
Stanislav tsmx@tut.by changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |NOTOURBUG
--- Comment #5 from Stanislav tsmx@tut.by --- (In reply to Alexandre Julliard from comment #4)
I'd just assume that MSDN is incorrect, it happens fairly often.
Wow, MSDN sure sucks. I actually found a fellow with visual studio and checked out LoadStringA on his PC, it behaves precisely as the Wine version.
Thanks for pointing it out, case closed.
https://bugs.winehq.org/show_bug.cgi?id=47762
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|NOTOURBUG |INVALID Status|RESOLVED |CLOSED CC| |z.figura12@gmail.com
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- Closing invalid. NOTOURBUG is for bugs in upstream components that Wine depends on.