On Tue, May 21, 2002 at 09:57:10PM +0200, Mehmet YASAR wrote:
Hi,
I've a small patch that allows me to get "Font Explorer Light" go further, both app are relying on a Windows bug.
For example take the following code (see the log) :
int main(int argc, char* argv[]) { int i; char buffer[20];
buffer[0] = buffer[1] = buffer[2] = 77; i = GetLocaleInfoA(0x409, LOCALE_IFIRSTDAYOFWEEK, buffer, 1);
printf("%d:%d ret=%d\n", buffer[0], buffer[1], i); return 0; }
On Win2K we have <54:77 ret=0> On Wine I have <0 :77 ret=1>
We see that MS returns 0 as failure but modifies buffer[0] ! The following patch should fix this.
Mehmet
--- /home/mehmet/CVS/wine/ole/ole2nls.c Sun Apr 28 15:42:21 2002 +++ ole2nls.c Tue May 21 21:33:58 2002 @@ -574,6 +574,12 @@ } /* if len=0 return only the length, don't touch the buffer*/ if (len) {
- /* We behave like Windows when len == 1 */
- if (len == 1)
- {
buf[0] = retString[0];return 0;- } lstrcpynA(buf,retString,len); return strlen(buf) + 1; }
Wrong, I'd guess (way too specific).
I'm almost 100% sure (well, maybe I'm the one who's wrong :) that Windows copies as many bytes len as you give it up to the retString size. And if len < strlen(retString), then it returns 0 *after* having filled a part of the buffer. Also, maybe there's a problem with terminating '\0' handling for some len values. I.e. I'm *sure* that it'd modify 2 bytes if you give it len 2, but still return 0 as the buffer size is too small.
It'd be good if you rechecked exact buffer writing behaviour under Windows regarding "not enough buffer space" due to small len, and also the windows behaviour in the special case when len is not enough to copy the trailing '\0' of retString into buffer.