March 2005 - Wine-Devel - list.winehq.org

About [ZH2005-02SA] Insecure tmp file creation in Wine
by Giovanni Delvecchio March 24, 2005

March 24, 2005

hello list, i noted that the patch provided ( http://www.winehq.org/hypermail/wine-devel/2005/03/0624.html ) to fix that problem isn't secure yet, because a symlink attack could be possible if /tmp is a mounted NFS file system. Indeed: 1)The name of the file in /tmp is easly predictable , it uses getpid(); 2)O_EXCL when used with O_CREAT, if the file already exists it is an error and the open will fail. O_EXCL is broken on NFS file systems, programs which rely on it for performing locking tasks will contain a race condition. Possible fix using tempnam() function to generate a psued-random string for tmp file name: _______________________________________________________________ --- misc/registry.c Thu Mar 24 13:36:43 2005 +++ misc/registry.c Thu Mar 24 13:46:46 2005 @@ -1222,12 +1222,11 @@ static LPSTR _get_tmp_fn(FILE **f) { LPSTR ret; - int tmp_fd,count; + int tmp_fd; - ret = _xmalloc(50); - for (count = 0;;) { - sprintf(ret,"/tmp/reg%lx%04x.tmp",(long)getpid(),count++); - if ((tmp_fd = open(ret,O_CREAT | O_EXCL | O_WRONLY,0666)) != -1) break; + for (;;) { + ret = tempnam("/tmp", "reg"); + if ((tmp_fd = open(ret,O_CREAT | O_EXCL | O_WRONLY,0600)) != -1) break; if (errno != EEXIST) { ERR("Unexpected error while open() call: %s\n",strerror(errno)); free(ret); _______________________________________________________________ Best regard, Giovanni Delvecchio -- ______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze

1 0

Re: Treeview plus/minus
by Jon Griffiths March 24, 2005

March 24, 2005

Hi George, >If I change the size to 18 the plus is drawn correctly >Does anybody knows anything about this ? The native controls draw a different kind of cross for large items, which looks a lot nicer. I added this but the initial threshold for deciding when to draw the large cross was too small, as reported by Ge Van Geldorp from the ReactOS crew - The thread starts here: http://www.winehq.com/hypermail/wine-devel/2004/10/0445.html The size was changed to 18 which seems to work (as you found yourself). I don't know what size or algorithm MS uses to determine when to switch the drawn style, but noone has reported an issue with this since then. You should maybe consider working with a more up to date Wine version, since that patch was committed over 2 months ago. Hope that helps, Jon "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

1 0

Re: [OLE #84] Don't use IsBadStringPtr on NULL pointers
by Alexandre Julliard March 24, 2005

March 24, 2005

Mike Hearn <mike(a)navi.cx> writes: > Don't use IsBadStringPtr on NULL pointers If the goal is to avoid exceptions, then it would be better to do that check directly in the IsBad* functions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Treeview plus/minus
by George Ginden March 24, 2005

March 24, 2005

Talking about the plus / minus symbols in the treeview control... Why with a size of 16 the plus symbol looks more like a small circle than a cross ? If I change the size to 18 the plus is drawn correctly Does anybody knows anything about this ? Regards. @@ -2329,7 +2330,7 @@ SelectObject(hdc, hOldPen); DeleteObject(hNewPen); - if (height < 16 || width < 16) + if (height < 18 || width < 18) {

1 0

[RFC] Pager: why do we implement WM_NCPAINT instead of WM_PAINT?
by Dimitrie O. Paun March 24, 2005

March 24, 2005

Hi folks, Does anyone know why the Pager common control (dlls/comctl32/pager.c) implements WM_NCPAINT instead of WM_PAINT? It is the only exception to the rule, all other controls implement WM_PAINT. -- Dimi.

2 1

World of Warcraft
by cyrix12＠cox.net March 24, 2005

March 24, 2005

Sorry to keep bugging you guys about this, but a recent patch broke the opengl mode of World of Warcraft again. It simply fails to start, similar to the d3d mode (except for the fact that I know why d3d mode doesn't work as of now). I was scanning through the traces and saw no errors though. Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure what to look for anyway. If anyone wants me to send a any sort of debug log (if, for instance, you don't have copy of WoW to test on), let me know (include what you'd want to see as well, if you don't mind). Thanks in advance, Darckness

3 7

Segfault in X11DRV_DIB_BuildColorTable (DIB_PAL_COLORS)
by Jesse D Zbikowski March 23, 2005

March 23, 2005

I am experiencing a crash during startup of an application (The Rosetta Stone 2.0.7a) under Wine. I reported this earlier on wine-users and after some debugging was advised to move to this list. The line causing a problem is dlls/x11drv/dib.c:425 417 HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL); 418 PALETTEENTRY pal_ents[256]; 419 WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize); 420 421 GetPaletteEntries(hpal, 0, 256, pal_ents); 422 423 for(i = 0; i < colors; i++, index++) 424 { =>425 colorTable[i].rgbRed = pal_ents[*index].peRed; 426 colorTable[i].rgbGreen = pal_ents[*index].peGreen; 427 colorTable[i].rgbBlue = pal_ents[*index].peBlue; 428 colorTable[i].rgbReserved = 0; 429 } This happens when X11DRV_DIB_BuildColorTable() is called with coloruse==DIB_PAL_COLORS, meaning we use an 8-bit palette. It seems to me that (LPBYTE)info must be corrupt and is giving a corrupt value to (WORD)index. Wine-dbg>p i 0 Wine-dbg>p colorTable[i] {rgbBlue=0, rgbGreen=0, rgbRed=0, rgbReserved=0} Wine-dbg>p pal_ents {{peRed=0, peGreen=0, peBlue=0, peFlags=0}, ... } Wine-dbg>p pal_ents[0] {peRed=, peGreen= Exception c0000005 Wine-dbg>p index 0x77aaec20 Wine-dbg>p *index No type or type mismatch Wine-dbg>p info fixme:winedbg:print_value ---error Here is the backtrace. fixme:font:GetKerningPairsW (0x1a28,0,(nil)): almost empty stub! First chance exception: page fault on read access to 0x77ab71cc in 32-bit code (0x7fea1e53). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7fea1e53 ESP:77aae66c EBP:77aaea98 EFLAGS:00010287( - 00 RISP1C) EAX:000022d0 EBX:7fef22c4 ECX:7786aee0 EDX:00000000 ESI:7e042900 EDI:77aaec20 Stack dump: 0x77aae66c: 00000044 00000000 00000100 77aae68c 0x77aae67c: 00000400 00000000 00000100 00000001 0x77aae68c: 00000000 00000080 00008000 00008080 0x77aae69c: 00800000 00800080 00808000 00c0c0c0 0x77aae6ac: 00c0dcc0 00f0caa6 00f0fbff 00a4a0a0 0x77aae6bc: 00808080 000000ff 0000ff00 0000ffff Backtrace: =>1 0x7fea1e53 X11DRV_DIB_BuildColorTable+0x173(physDev=0x7e042408, coloruse=0x1, depth=0x8, info=0x77aaebf8) [/home/jesse/wine/dlls/x11drv/dib.c:425] in x11drv (0x77aaea98) 2 0x7feaa20b X11DRV_DIB_CreateDIBSection+0x22b(physDev=0x7e042408, bmi=0x77aaebf8, usage=0x1, bits=0x7d7703ec, section=0x0, offset=0x0, ovr_pitch=0x0) [/home/jesse/wine/dlls/x11drv/dib.c:4749] in x11drv (0x77aaeb5c) 3 0x77824ab3 DIB_CreateDIBSection+0xa3(hdc=0x5b5c, bmi=0x77aaebf8, usage=0x1, bits=0x7d7703ec, section=0x0, offset=0x0, ovr_pitch=0x0) [/home/jesse/wine/dlls/gdi/dib.c:1107] in gdi32 (0x77aaeb90) 4 0x77824b28 CreateDIBSection+0x48(hdc=0x5b5c, bmi=0x77aaebf8, usage=0x1, bits=0x7d7703ec, section=0x0, offset=0x0) [/home/jesse/wine/dlls/gdi/dib.c:1125] in gdi32 (0x77aaebb8) 5 0x690323bb 1680 in iml32 (0x7b1c7b8c) 6 0x00000264 (0x00000010) 7 0x00000000 (0x00000000) 0x7fea1e53 X11DRV_DIB_BuildColorTable+0x173 [/home/jesse/wine/dlls/x11drv/dib.c:425] in x11drv: movzbl 0xfffffbf4(%ebp,%eax,4),%eax 425 colorTable[i].rgbRed = pal_ents[*index].peRed; I can add a breakpoint before we get here and try to step through, although the flow seems to skip around a bit. Wine-dbg>b X11DRV_DIB_BuildColorTable Breakpoint 1 at 0x7fea1d04 X11DRV_DIB_BuildColorTable+0x24 [/home/jesse/wine/dlls/x11drv/dib.c:377] in x11drv Wine-dbg>cond 1 (coloruse == 1) 417 HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL); Wine-dbg>n 419 WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize); Wine-dbg>n 417 HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL); Wine-dbg>n 421 GetPaletteEntries(hpal, 0, 256, pal_ents); Wine-dbg>n 419 WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize); Wine-dbg>n 421 GetPaletteEntries(hpal, 0, 256, pal_ents); Wine-dbg>n 423 for(i = 0; i < colors; i++, index++) Wine-dbg>n 421 GetPaletteEntries(hpal, 0, 256, pal_ents); Wine-dbg>n 423 for(i = 0; i < colors; i++, index++) Wine-dbg>n 425 colorTable[i].rgbRed = pal_ents[*index].peRed; Wine-dbg>s 868 switch(rec->ExceptionCode) Wine-dbg>s 867 { Wine-dbg>s 868 switch(rec->ExceptionCode) Wine-dbg>s 873 if (!(rec->ExceptionCode = VIRTUAL_HandleFault( (void *)rec->ExceptionInformation[1] ))) Wine-dbg>s 1125 DWORD ret = EXCEPTION_ACCESS_VIOLATION; I am using the latest Wine I built from CVS, after first encountering this problem in the 20050111 and 20050310 Gentoo ebuilds. I have a Linux 2.6.11 system with glibc 2.3.4 20040808 (including nptl), Xorg-x11 6.8.2-rc2 (Trident Cyberblade/i1 "trident_drv.o") @1024x768 16bpp. Also tried kernels 2.6.9 & 2.6.10 and 800x600 24bpp mode. Would appreciate any advice on how to proceed. http://www.winehq.org/hypermail/wine-users/2005/03/0293.html http://www.winehq.org/hypermail/wine-users/2005/03/0296.html http://appdb.winehq.org/appview.php?appId=1867 Thanks, Jesse Z.

2 2

[AppDB] Application queue: Getting ahead of me.
by Tony Lambregts March 23, 2005

March 23, 2005

I will be unable to tend to the application queue for the next week and as a matter of fact I am already behind maintaining it. (sorry). If one of you good souls (with administrative rights) could take could take care of it for the next week I would really appreciate it. Thanks. -- Tony Lambregts

1 0

World of Warcraft
by cyrix12＠cox.net March 23, 2005

March 23, 2005

What I meant to say in the previous message was something along the lines of "Here's an opengl trace; let me know if you need any others." Unfortunately, it seemed to come out in some other language which I am not familiar in. So here's the opengl trace. Darckness

1 0

Re: DDRAW: Surface locking patch, take 2
by Tony Lambregts March 23, 2005

March 23, 2005

Matthew Mastracci wrote: > This patch (correctly) fixes the locking problems in SimCity 3000. We > now check to see if the blit src and dest are the same surface and, if > so, we make sure to lock the surface only once and, in the case of > BltFast, re-adjust the surface pointers. This patch also makes sure the > surfaces are correctly unlocked if a bad rectangle is passed. > > ChangeLog > Correctly lock and unlock surface for a single-surface Blt() and > BltFast() call. > Is there anything wrong with this patch. http://www.winehq.org/hypermail/wine-patches/2005/03/0113.html It works fine for me (and SimCity). and I was wondering why it was not applied. -- Tony Lambregts

1 0