- Wine-Devel - list.winehq.org

[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

Riched20: regression "beta" not shown; tab-wish
by Tobias Burnus March 23, 2005

March 23, 2005

Hello, first I'd really like to thank the riched20 workers, notably Krzysztof Foltman and Phil Krylov. For the application Diamond it made a big difference: Instead of "[[Aring]]" etc. one sees the proper symbol and it looks much nicer. But the biggest advantage is that one can now copy or save the text; before the app was simply crashing! Regression: One of the later riched20 patches, possibly http://cvs.winehq.org/patch.py?id=16672, caused a regression with the richedit control in Diamond. Before it showed a beta character from the Symbol font, now it only shows a box ("[]"). If one saves the output (rtf export) one sees ------------------- {\rtf1\ansi\ansicpg1252\uc1\deff0\deflang1031\deflangfe1031{\fonttbl{\f0 Times New Roman;} {\f1\fcharset0 System;} {\f2\fcharset2 Symbol;} }{\*\generator Wine Riched20 2.0.????;}\pard\li0\fi0\ri0{\b\fs18\ul Bibliographic data} \par\pard\li0\fi0\ri0 [...] \par\pard\li0\fi0\ri0{\fs18 }{\i\fs18 b}{\fs18 = 5.8312(2) \'c5} \par\pard\li0\fi0\ri0{\fs18 }{\i\fs18 c}{\fs18 = 7.9564(2) \'c5} \par\pard\li0\fi0\ri0{\fs18 }{\fs18\f2 \u61538?}{\fs18 = 100.77(0) \u176?} ------------------- In the last line, after the \f2 (Symbol font), there should be a beta ("b" + Symbol font). Trace (starting from the "b = 5.8312(2)"): ------------ trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 177), counted = 177, len = 1, txt = "L"b"", flags=00000000, fx&mask = 44000002 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 178), counted = 178, len = 14, txt = "L" = 5.8312(2) \00c5"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 192), counted = 192, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets para, real ofsp = 193, counted = 193 trace:richedit:ME_CheckCharOffsets run, real ofs = 0 (+ofsp = 193), counted = 193, len = 1, txt = "L"\t"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 194), counted = 194, len = 1, txt = "L"c"", flags=00000000, fx&mask = 44000002 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 195), counted = 195, len = 14, txt = "L" = 7.9564(2) \00c5"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 209), counted = 209, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets para, real ofsp = 210, counted = 210 trace:richedit:ME_CheckCharOffsets run, real ofs = 0 (+ofsp = 210), counted = 210, len = 1, txt = "L"\t"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 211), counted = 211, len = 1, txt = "L"\f062"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 212), counted = 212, len = 14, txt = "L" = 100.77(0) \00b0"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 226), counted = 226, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 ------------ * * * * One feature request: Currently, tabs are shown as box ("[]"), how about replacing them with a simple space - that would increase the readability a lot. Compare: WINE-CVS: http://www.physik.fu-berlin.de/~tburnus/wine/diamond3.png Windows: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list.png Tobias

1 0

Re: Native stack overlapping system heap base address on some systems
by Steven Edwards March 23, 2005

March 23, 2005

Hi, --- Alexandre Julliard <julliard(a)winehq.org> wrote: > > Surprise surprise, 0x7fffb000 + (1024 * 20) == 0x80000000 This looks like what I have seen on some users systems running Suse 9.2. Some users see errors like this err:virtual:NtMapViewOfSection map_file_into_view 0x80000000 1000000 000000000 failed err:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not available > No it doesn't overlap, a 20K mapping at 7fffb000 ends at > 7fffffff. Most likely that kernel is configured for a 2Gb virtual > address space. I will recompile a kernel with 2GB and see what happens. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Re: lostwages/templates/en contributing.template j ...
by Jakob Eriksson March 23, 2005

March 23, 2005

I submitted a patch for all casts I could find with that little grep: find . -name "*.[ch]" | xargs egrep "\) *Heap(Re)?Alloc" Jeremy Newman wrote: >ChangeSet ID: 16817 >CVSROOT: /opt/cvs-commit >Module name: lostwages >Changes by: jnewman(a)wine.codeweavers.com 2005/03/23 08:56:08 > >Modified files: > templates/en : contributing.template janitorial.template > resources.template sending_patches.template > status.template > >Log message: > Mike McCormack <mike(a)codeweavers.com> > * suggest janitoral project > * other updates and W3 fixes > >Patch: http://cvs.winehq.org/patch.py?id=16817 > >Old revision New revision Changes Path > 1.24 1.25 +3 -3 lostwages/templates/en/contributing.template > 1.73 1.74 +17 -7 lostwages/templates/en/janitorial.template > 1.11 1.12 +1 -1 lostwages/templates/en/resources.template > 1.11 1.12 +2 -0 lostwages/templates/en/sending_patches.template > 1.33 1.34 +1 -1 lostwages/templates/en/status.template > > >

1 0

Native stack overlapping system heap base address on some systems
by Mike Hearn March 23, 2005

March 23, 2005

Hi, Bug #2741 comes from a user who was able to grab a dump of the VM mappings when the following error occurred: HEAP_CreateSystemHeap system heap base address 0x80000000 not available I know people have been seeing this intermittently for a while now, we have a few CodeWeavers support tickets with this problem too. The issue seems to be that the Linux native (main thread) stack was allocated here: 7fffb000 20K rwx-- [ stack ] Surprise surprise, 0x7fffb000 + (1024 * 20) == 0x80000000 Unfortunately I lack enough knowledge about the kernels VM algorithms to say why it's being allocated here. For comparison on my Fedora Core 3 machine: fef0d000 16K rwx-- [ stack ] One other thing I don't understand. It seems the stack and the system heap overlap by exactly 1 byte, otherwise the mmap would not fail. But, this area is (theoretically) being protected by the preloader: so how can this be? There is something I'm missing here, I suspect an off-by-one error in my arithmetic. thanks -mike

2 1