July 2001 - Wine-Devel - list.winehq.org

glibc bug mmap/malloc
by Andreas Mohr July 17, 2001

July 17, 2001

[yeah, it's glibc bug time AGAIN] Hello all, I just wanted to let you all know that I found what I believe to be a glibc malloc bug. (yes, this happens even with 2.4.6 and latest Debian glibc 2.2.3-6). This is the only thing I did today, BTW. When Wine loads a very large (129 MB) exe file, it does an mmap() on it. After that it tries to do some malloc()s. That fails, which causes the entirely loading/execution of that file to abort. Thus I did malloc()/free() in a for loop after that 129 MB mmap() to test the problematic behaviour. Output: trace:module:map_image mapped PE file at 0x8051000-0xfc45000 err:virtual:VIRTUAL_CreateView now that the PE file has been mmap() /dev/zero:ed, we do some other malloc()s: malloc of 4 bytes: 0x804d878 malloc of 8 bytes: 0x804d878 malloc of 12 bytes: 0x804d878 malloc of 16 bytes: 0x804d878 malloc of 20 bytes: 0x804db20 <---- (chunk size optimization algorithm) malloc of 24 bytes: 0x804db20 <---- ("") malloc of 28 bytes: 0x804e7f8 <---- ("") malloc of 32 bytes: 0x804e7f8 malloc of 36 bytes: 0x804e7f8 . . . malloc of 10224 bytes: 0x804e7f8 malloc of 10228 bytes: 0x804e7f8 malloc of 10232 bytes: 0x804e7f8 up to 0x8050fef malloc of 10236 bytes: (nil) (0x8050ff3, which probably touches mmap() management headers) malloc of 10240 bytes: (nil) . . . malloc of 131052 bytes: (nil) malloc of 131056 (0x1fff0) bytes: (nil) ... malloc of 131060 bytes: 0x404c2008 malloc of 131064 bytes: 0x404c2008 . . . You can clearly see that malloc() is able to squeeze up to 10232 bytes into the memory range just before the mmap()ed area, but when it gets slightly larger, it is NOT capable of switching to an entirely different memory area, throws its arms up in desperation and simply returns a shabby NULL. It only uses a new memory area in case the values get *much* larger, i.e. at least 131060 bytes. This is a BUG. (IMHO) What else should it be ? I already contacted Ulrich Drepper about it, and I'll hopefully get a positive reply soon. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Microsoft Windows: Made for the Internet The Internet: Made for Unix

1 0

Re: Significant change to WINEPS - please test!
by Gerard Patel July 17, 2001

July 17, 2001

At 07:29 PM 15/07/2001 -0500, you wrote: >So please give me your feedback. I particularly want to know if it >breaks anything before I submit it. Anything ? everything is a better word. I use a 'latin' language. No unicode for me. I test with the software I use to send this mail. There is a 'preview' feature and I can preview (and print) a mail. This is working fine with current Cvs. If I use your patch, most characters in the mail body, are overlayed, printed scattered in black heaps with small lines all around , strangely evoking some insects. Pretty funny :-) If my description is not clear, I can send you a screen capture. Strangely the page header and footer are still correct, though. Gerard

2 1

Re: Small OpenGL fix
by Alexandre Julliard July 17, 2001

July 17, 2001

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > In the current code, there seems to be two different mechanisms for driver > calling : > > - one that is 'GDI' specific with the 'dc->funcs->pFUNC_NAME' sort of calls > > - the other for 'USER' with 'USER_Driver.pFUNC_NAME' > > So which one of the two methods should I use the 'WGL' that is neither in > GDI nor in USER ? You can't really use either. The GDI one requires calling DC_GetDCPtr which you cannot do from outside GDI, and the USER one requires a reference to a global variable that isn't visible outside USER. A possible way is to use the Escape function and add a few x11drv-specific escape codes. But first it would probably be a good thing to check how opengl32 is implemented under Windows; I have no idea how it works, but it probably needs some way to communicate with the graphics driver, and we could use the same mechanism. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Small OpenGL fix
by Alexandre Julliard July 17, 2001

July 17, 2001

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > This is more a problem of inter-dependencies of X11DRV and USER32 (as the > former should NEVER be loaded before the latter)... But as I could not fix > this problem, I prefered going 'around' the problem :-) The dependencies between x11drv and user should certainly be fixed, but the real problem is that opengl32 and ddraw import x11drv at all. x11drv is an internal driver and should never be imported by any dll. Anybody feeling like fixing that? -- Alexandre Julliard julliard(a)winehq.com

2 1

using cvs diff
by Bill Medland July 17, 2001

July 17, 2001

I can't see it in TFM I thought I was keeping an eye on what patches had actually been applied to the wine source (especially to see if mine had) by using "cvs diff wine". It seemed to be working but I now realise it wasn't. I guess it was diffing my local code against the corresponding revisions. How do I diff my current set of code against the current cvs? Bill

3 2

ChangeDisplaySettings
by Travis Michielsen July 17, 2001

July 17, 2001

Hi, I was planning on implementing ChangeDisplaySettingsA soon but I'm not certain on how to do it. I have been browsing the source tree and was following the methods used by DirectDraw and was considering a similar approach. While I was browsing the source, I was eventually lead to dlls/x11drv/xvidmode.c which contains most of the functions that I will probably need. But I still have a few concerns: 1) Is the x11drv used for ddraw AND the gdi or just one? 2) what is the best way to query if the video exists? without knowing syncs? 3) and if i need to know syncs how do I find them? Another question I have is about pixel depth. From what I understand, it is imposible to change the pixel format of the screen while X is running. However, it is possible to start more than one X server with different configs (and depth) which we could use if we have to but probably not a good idea. Of course another posibility is to emulate the pixel depth, but that would probably cause performance problems, especially when used by games. Anyone have any suggestions or should we just leave changing depths as unimplemented? Thanks! - Travis Michielsen __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

2 1

DrawText
by Travis Michielsen July 17, 2001

July 17, 2001

Hi all, I have put together a quick patch that SHOULD fully implement the DrawText functions. However, I have not had time to thoroughly tested most of the logic so I thought I would post it here rather than sending it directly to the patches list. I welcome any/all comments/suggestions. - Travis Michielsen Index: wine/dlls/user/text.c =================================================================== RCS file: /home/wine/wine/dlls/user/text.c,v retrieving revision 1.12 diff -u -r1.12 text.c --- wine/dlls/user/text.c 2001/07/17 00:51:00 1.12 +++ wine/dlls/user/text.c 2001/07/17 13:55:22 @@ -235,6 +235,7 @@ int prefix_x = 0; int prefix_end = 0; TEXTMETRICW tm; + int lmargin = 0, rmargin = 0; int x = rect->left, y = rect->top; int width = rect->right - rect->left; int max_width = 0; @@ -242,10 +243,8 @@ TRACE("%s, %d , [(%d,%d),(%d,%d)]\n", debugstr_wn (str, count), count, rect->left, rect->top, rect->right, rect->bottom); - if(dtp) { - FIXME("Ignores params:%d,%d,%d,%d\n", dtp->cbSize, - dtp->iTabLength, dtp->iLeftMargin, dtp->iRightMargin); - } + if (dtp) TRACE("Params: iTabLength=%d, iLeftMargin=%d, iRightMargin=%d\n", + dtp->iTabLength, dtp->iLeftMargin, dtp->iRightMargin); if (!str) return 0; if (count == -1) count = strlenW(str); @@ -258,8 +257,17 @@ else lh = tm.tmHeight; + if (dtp) + { + lmargin = dtp->iLeftMargin * tm.tmAveCharWidth; + rmargin = dtp->iRightMargin * tm.tmAveCharWidth; + if (!(flags & (DT_CENTER | DT_RIGHT))) + x += lmargin; + dtp->uiLengthDrawn = 0; //This param RECEIVES number of chars processed + } + if (flags & DT_TABSTOP) - tabstop = flags >> 8; + tabstop = dtp ? dtp->iTabLength : flags >> 8; if (flags & DT_EXPANDTABS) { @@ -292,7 +300,7 @@ if (flags & DT_SINGLELINE) { - if (flags & DT_VCENTER) y = rect->top + + if (flags & DT_VCENTER) y = rect->top + (rect->bottom - rect->top) / 2 - size.cy / 2; else if (flags & DT_BOTTOM) y = rect->bottom - size.cy; @@ -312,7 +320,7 @@ if (flags & DT_WORD_ELLIPSIS) flags |= DT_WORDBREAK; - if (flags & DT_PATH_ELLIPSIS) + if (flags & DT_PATH_ELLIPSIS) { WCHAR* lastBkSlash = NULL; WCHAR* lastFwdSlash = NULL; @@ -320,14 +328,11 @@ line[totalLen] = '\0'; lastBkSlash = strrchrW(line, BACK_SLASHW[0]); lastFwdSlash = strrchrW(line, FORWARD_SLASHW[0]); - fnameDelim = lastFwdSlash ? lastFwdSlash : lastBkSlash; - if (lastBkSlash && lastFwdSlash) /* which is last? */ - if (lastBkSlash > lastFwdSlash) - fnameDelim = lastBkSlash; + fnameDelim = lastBkSlash > lastFwdSlash ? lastBkSlash : lastFwdSlash; if (fnameDelim) fnameLen = &line[totalLen] - fnameDelim; - else + else fnameDelim = (WCHAR*)str; strcpyW(swapStr, ELLIPSISW); @@ -343,16 +348,16 @@ } len = MAX_STATIC_BUFFER; - TEXT_NextLineW(hdc, swapStr, &count, line, &len, width, flags); + TEXT_NextLineW(hdc, swapStr, &count, line, &len, width, flags); /* if only the ELLIPSIS will fit, just let it be clipped */ len = max(3, len); GetTextExtentPointW(hdc, line, len, &size); /* FIXME: - * NextLine uses GetTextExtentPoint for each character, + * NextLine uses GetTextExtentPoint for each character, * rather than GetCharABCWidth... So the whitespace between - * characters is ignored in the width measurement, and the + * characters is ignored in the width measurement, and the * reported len is too great. To compensate, we must get * the width of the entire line and adjust len accordingly. */ @@ -365,10 +370,10 @@ if (fnameLen < len-3) /* some of the path will fit */ { /* put the ELLIPSIS between the path and filename */ - strncpyW(swapStr, &line[fnameLen+3], len-3-fnameLen); + strncpyW(swapStr, &line[fnameLen+3], len-3-fnameLen); swapStr[len-3-fnameLen] = '\0'; - strcatW(swapStr, ELLIPSISW); - strncpyW(swapStr+strlenW(swapStr), &line[3], fnameLen); + strcatW(swapStr, ELLIPSISW); + strncpyW(swapStr+strlenW(swapStr), &line[3], fnameLen); } else { @@ -382,12 +387,15 @@ line[len] = '\0'; strPtr = NULL; } + if (flags & DT_MODIFYSTRING) + strcpyW(str, swapStr); } } if (!(flags & DT_CALCRECT)) { - if (!ExtTextOutW(hdc, x, y, (flags & DT_NOCLIP) ? 0 : ETO_CLIPPED, - rect, line, len, NULL )) return 0; + if (!ExtTextOutW( hdc, x, y, + ( (flags & DT_NOCLIP) ? 0 : ETO_CLIPPED ) | ( (flags & DT_RTLREADING) ? 0 : ETO_RTLREADING ), + rect, line, len, NULL )) return 0; if (prefix_offset != -1) { HPEN hpen = CreatePen( PS_SOLID, 1, GetTextColor(hdc) ); @@ -410,20 +418,35 @@ break; } } + if (dtp) + dtp->uiLengthDrawn += len; } while (strPtr); + if (flags & DT_CALCRECT) { rect->right = rect->left + max_width; rect->bottom = y; + if (dtp) + rect->right += lmargin + rmargin; } return y - rect->top; } /*********************************************************************** - * DrawTextA (USER32.@) + * DrawTextW (USER32.@) */ -INT WINAPI DrawTextA( HDC hdc, LPCSTR str, INT count, LPRECT rect, UINT flags ) +INT WINAPI DrawTextW( HDC hdc, LPCWSTR str, INT count, + LPRECT rect, UINT flags ) +{ + return DrawTextExW(hdc, str, count, rect, flags, NULL); +} + +/*********************************************************************** + * DrawTextExA (USER32.@) + */ +INT WINAPI DrawTextExA( HDC hdc, LPCSTR str, INT count, + LPRECT rect, UINT flags, LPDRAWTEXTPARAMS dtp ) { WCHAR *wstr; INT ret = 0; @@ -437,32 +460,19 @@ { MultiByteToWideChar( CP_ACP, 0, str, count, wstr, wcount ); ret = DrawTextExW( hdc, wstr, wcount, rect, flags, NULL ); + if (flags & DT_MODIFYSTRING) + WideCharToMultiByte( CP_ACP, 0, wstr, -1, str, count, NULL, NULL ); HeapFree(GetProcessHeap(), 0, wstr); } return ret; } /*********************************************************************** - * DrawTextW (USER32.@) - */ -INT WINAPI DrawTextW( HDC hdc, LPCWSTR str, INT count, - LPRECT rect, UINT flags ) -{ - return DrawTextExW(hdc, str, count, rect, flags, NULL); -} - -/*********************************************************************** - * DrawTextExA (USER32.@) + * DrawTextA (USER32.@) */ -INT WINAPI DrawTextExA( HDC hdc, LPCSTR str, INT count, - LPRECT rect, UINT flags, LPDRAWTEXTPARAMS dtp ) +INT WINAPI DrawTextA( HDC hdc, LPCSTR str, INT count, LPRECT rect, UINT flags ) { - TRACE("(%d,%s,%d,%p,0x%08x,%p)\n",hdc,debugstr_an(str,count),count,rect,flags,dtp); - if(dtp) { - FIXME("Ignores params:%d,%d,%d,%d\n",dtp->cbSize, - dtp->iTabLength,dtp->iLeftMargin,dtp->iRightMargin); - } - return DrawTextA(hdc,str,count,rect,flags); + return DrawTextExA( hdc, str, count, rect, flags, NULL ); } /*********************************************************************** __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

1 0

Re: another debugstr patch
by Alexandre Julliard July 17, 2001

July 17, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > BTW, Alexandre, why didn't you apply my "debugstr patch" from Jun 04 ? It got lost somewhere; I've applied it now. BTW for everybody, when you submitted a patch and didn't see it applied and didn't hear anything about it, *please* resubmit or ask me what's going on. Patches can get dropped for multiple reasons, and it's your responsibility to follow what happens to your patch, until it is either applied or you know why it wasn't. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Mouse trouble
by Alexandre Julliard July 17, 2001

July 17, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I did consider that, but who's going to intercept and handle that message? > It's not an operation that is or should be known outside of the x11drv, so > sending the window a custom message will either conflict with some other > message, or get the message ignored (I doubt DefWindowProc passes custom > messages back to x11drv or anything). Or did you have any particular ideas > in this area? You can set a new window procedure to intercept the message, and pass all other messages straight through to the original window procedure. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Mouse trouble
by Alexandre Julliard July 17, 2001

July 17, 2001

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Known bug in the current CVS. Turn dxgrab off. If it's on, mouse events > are lost. I'm working on it, but have not yet thought of a way to fix it; > I need to run a procedure (GrabPointer) in the context of the thread that > owns the window that gets the grab. My latest idea was to queue an APC to > the owner of the window, but QueueUserAPC requires a thread handle, while > GetWindowThreadProcessId only returns a thread ID. I'd strongly suggest using some kind of SendMessage instead of QueueUserAPC. -- Alexandre Julliard julliard(a)winehq.com

2 1