wine-devel April 2006

wine-devel@winehq.org

176 participants
334 discussions

Re: DirectDraw status
by Stefan Dösinger 09 Apr '06

09 Apr '06

Hi, > Too many games are unplayable because of slowness, "Omikron : The Nomad > Soul" is one of them and your patch give me hope to see it working better ( > actually it works with some graphic artifacs, but the in-game menu is > painfully slow ). However i tried your patch and now i get this error box > running demo : "DirectX error : impossible to get the surface attached to > the primary surface". Demo is available here : > http://www.3dgamers.com/dlselect/games/omikron/omikrondemo_full.exe.html Hm. I will download the file when I'm back at the university, but I have holidays now for 2 weeks :) Note that the ddraw merge doen't target a speed improvement for now, and wined3d is a little bit slower than the currect ddraw Direct3D code. So unless you hit a bug in the ddraw code, the performance won't improve. > I've also tested Fallout, it works great, but the fade-in/out problem isn't > completely "gone" : no more slowness but no more fade effect too :). > > Later i'll test more games, should i forward you results on this ML ? Yeah, report them to wine-devel. But I'm afraid that most d3d games, except the ones I tried will fail for now. Thanks for the report, Stefan

1 0

Re: winedbg: resend: analyse far calls in be_i386_is_func_call
by Eric Pouech 09 Apr '06

09 Apr '06

Jeff L wrote: > Fixes some things Eric pointed out. Have not tested the far calls as I > don't have anything that generates them. > > This patch came about when I was looking at why single stepping seemed > to stuff up after a call. It breaks down the calls for 32 bit mode > calls but not necessarily 16 and not 64 bit calls. It is a fairly messy > area of knowledge and I could do with assistance as to how the 16/32/64 > bit modes work. > > Change log: Add code to analyse far calls in be_i386_is_func_call > instead of only near calls. > > Jeff Latimer a lot of things still look wrong to me... - first of all, a lot of code should be factorized - the callee should really be filled with the way the address of the call is stored in the insn (for example, you return a modeflat for a relative call from a 16 bit segment...) - lots of computation for negative displacements are wrong - segment is always expressed as an unsigned short (even in ADDRESS structure), so you shouldn't convert it to an int... - ... A+ > > Index: programs/winedbg/be_i386.c > =================================================================== > RCS file: /home/wine/wine/programs/winedbg/be_i386.c,v > retrieving revision 1.6 > diff -u -r1.6 be_i386.c > --- programs/winedbg/be_i386.c 21 Mar 2006 19:22:51 -0000 1.6 > +++ programs/winedbg/be_i386.c 8 Apr 2006 14:30:45 -0000 > @@ -380,28 +380,243 @@ > > static unsigned be_i386_is_func_call(const void* insn, ADDRESS* callee) > { > +#define f_mod(byte) ((byte)>>6) > +#define f_reg(byte) (((byte)>>3)&0x7) > +#define f_rm(byte) ((byte)&0x7) > BYTE ch; > - int delta; > + BYTE mod, reg, rm; > + BYTE delta8; > + short delta16; > + int delta = 0; > + int segment = 0; > + unsigned short segment16; > > if (!dbg_read_memory(insn, &ch, sizeof(ch))) return FALSE; > switch (ch) > { > - case 0xe8: > - dbg_read_memory((const char*)insn + 1, &delta, sizeof(delta)); > - > + case 0xe8: /* Call near, relative to next instruction */ > + callee->Mode = get_selector_type(dbg_curr_thread->handle, &dbg_context, dbg_context.SegCs); > + if (callee->Mode == AddrMode1616) { > + if (!dbg_read_memory((const char*)insn + 1, &delta16, sizeof(delta16))) > + return FALSE; > + delta = delta16; /* Align to 32 bits */ > + delta &= 0xffff; in this case, the callee should be kept as AddrMode1616, not in flat mode. you shouldn't either crop delta to a 16 bit value, especially it's wrong when delta is negative > + } else { > + if (!dbg_read_memory((const char*)insn + 1, &delta, sizeof(delta))) > + return FALSE; > + } > callee->Mode = AddrModeFlat; > callee->Offset = (DWORD)insn; > - be_i386_disasm_one_insn(callee, FALSE); > + be_i386_disasm_one_insn(callee, FALSE); > callee->Offset += delta; > > return TRUE; > - case 0xff: > + > + case 0xff: /* Call far, absolute address */ > if (!dbg_read_memory((const char*)insn + 1, &ch, sizeof(ch))) > return FALSE; > - ch &= 0x38; > - if (ch != 0x10 && ch != 0x18) return FALSE; > - /* fall through */ > - case 0x9a: > + rm = f_rm(ch); /* Extract ModR/M byte */ > + reg = f_reg(ch); > + mod = f_mod(ch); > + if (reg != 0x02 && reg != 0x03) return FALSE; > + if (reg == 0x02) { /* Same segment */ > + switch(mod) > + { > + case 0x00: /* Register operand */ > + callee->Mode = AddrModeFlat; > + switch (rm) > + { > + case 0x00: > + delta = dbg_context.Ebx + dbg_context.Esi; > + break; > + case 0x01: > + delta = dbg_context.Ebx + dbg_context.Edi; > + break; > + case 0x02: > + delta = dbg_context.Ebp + dbg_context.Esi; > + break; > + case 0x03: > + delta = dbg_context.Ebp + dbg_context.Edi; > + break; > + case 0x04: > + delta = dbg_context.Esi; > + break; > + case 0x05: > + delta = dbg_context.Edi; > + break; > + case 0x06: > + if (!dbg_read_memory((const char*)insn + 2, &delta, sizeof(2))) /* disp16 */ > + return FALSE; this is ugly. it'll work but, it would be cleaner to make it with reading delta16 (as a short), then cast the short to an int > + break; > + case 0x07: > + delta = dbg_context.Ebx; > + break; > + } > + break; > + case 0x01: /* Disp8 operand */ > + callee->Mode = AddrModeFlat; > + if (!dbg_read_memory((const char*)insn + 2, &delta8, sizeof(delta8))) > + return FALSE; > + delta = delta8; > + switch (rm) > + { > + case 0x00: > + delta += dbg_context.Ebx + dbg_context.Esi; > + break; > + case 0x01: > + delta += dbg_context.Ebx + dbg_context.Edi; > + break; > + case 0x02: > + delta += dbg_context.Ebp + dbg_context.Esi; > + break; > + case 0x03: > + delta += dbg_context.Ebp + dbg_context.Edi; > + break; > + case 0x04: > + delta += dbg_context.Esi; > + break; > + case 0x05: > + delta += dbg_context.Edi; > + break; > + case 0x06: > + delta += dbg_context.Ebp; > + break; > + case 0x07: > + delta += dbg_context.Ebx; > + break; > + } > + break; > + case 0x02: /* Disp16 or Disp32 bit operand */ > + callee->Mode = get_selector_type(dbg_curr_thread->handle, &dbg_context, dbg_context.SegCs); > + if (callee->Mode == AddrMode1616) { > + if (!dbg_read_memory((const char*)insn + 2, &delta16, sizeof(delta16))) > + return FALSE; > + delta = delta16; /* Align to 32 bits */ > + delta &= 0xffff; > + } else { > + if (!dbg_read_memory((const char*)insn + 2, &delta, sizeof(delta))) > + return FALSE; > + } > + callee->Mode = AddrModeFlat; > + switch (rm) > + { > + case 0x00: > + delta += dbg_context.Ebx + dbg_context.Esi; > + break; > + case 0x01: > + delta += dbg_context.Ebx + dbg_context.Edi; > + break; > + case 0x02: > + delta += dbg_context.Ebp + dbg_context.Esi; > + break; > + case 0x03: > + delta += dbg_context.Ebp + dbg_context.Edi; > + break; > + case 0x04: > + delta += dbg_context.Esi; > + break; > + case 0x05: > + delta += dbg_context.Edi; > + break; > + case 0x06: > + delta += dbg_context.Ebp; > + break; > + case 0x07: > + delta += dbg_context.Ebx; > + break; > + } > + break; > + case 0x03: /* Register operand */ > + callee->Mode = AddrModeFlat; > + switch (rm) > + { > + case 0x00: > + delta = dbg_context.Eax; > + break; > + case 0x01: > + delta = dbg_context.Ecx; > + break; > + case 0x02: > + delta = dbg_context.Edx; > + break; > + case 0x03: > + delta = dbg_context.Ebx; > + break; > + case 0x04: > + delta = dbg_context.Esp; > + break; > + case 0x05: > + delta = dbg_context.Ebp; > + break; > + case 0x06: > + delta = dbg_context.Esi; > + break; > + case 0x07: > + delta = dbg_context.Edi; > + break; > + } > + break; > + default: /* Disp32 bit operand */ > + if (!dbg_read_memory((const char*)insn + 2, &delta, sizeof(delta))) > + return FALSE; > + break; > + } > + > + callee->Offset = delta; > + > + return TRUE; > + } > + else if (reg == 0x03) /* Indirect Far call into other segment */ > + { > + far char * faraddr; you shouldn't need the far here (it brings nothing) > + /* Extract the far address of the indirect address */ > + if (dbg_read_memory((const char*)insn + 2, &faraddr, sizeof(faraddr))) > + return FALSE; > + /* Extract the far address of the callee */ > + if (dbg_read_memory((const char*)faraddr + sizeof(delta), &segment16, sizeof(segment16))) > + return FALSE; > + segment = segment16; > + callee->Mode = get_selector_type(dbg_curr_thread->handle, &dbg_context, (int) &segment); > + if (callee->Mode == AddrMode1616) { > + if (dbg_read_memory((const char*)faraddr, &delta16, sizeof(delta16))) > + return FALSE; > + delta = delta16; /* Align to 32 bits */ > + delta &= 0xffff; > + } else { > + if (dbg_read_memory((const char*)faraddr, &delta, sizeof(delta))) > + return FALSE; > + } > + callee->Mode = AddrMode1632; /* We have made a 32 address so say so */ > + callee->Segment = segment; > + callee->Offset = delta; /* absolute address not an offset */ > + > + return TRUE; > + } > + > + WINE_FIXME("Unsupported yet call insn (0x%02x) at %p\n", ch, insn); > + return FALSE; > + > + case 0x9a: /* Call far, absolute address in operand */ > + if (dbg_read_memory((const char*)insn + 1 + sizeof(delta), &segment16, sizeof(segment16))) > + return FALSE; > + segment = segment16; > + callee->Mode = get_selector_type(dbg_curr_thread->handle, &dbg_context, dbg_context.SegCs); > + if (callee->Mode == AddrMode1616) { > + if (!dbg_read_memory((const char*)insn + 1, &delta16, sizeof(delta16))) > + return FALSE; > + delta = delta16; /* Align to 32 bits */ > + delta &= 0xffff; > + } else { > + if (!dbg_read_memory((const char*)insn + 1, &delta, sizeof(delta))) > + return FALSE; > + } > + > + callee->Mode = AddrMode1632; /* We have made a 32 address so say so */ > + callee->Segment = segment; > + callee->Offset = delta; /* absolute address not an offset */ > + > + return TRUE; > + > case 0xCD: > WINE_FIXME("Unsupported yet call insn (0x%02x) at %p\n", ch, insn); > /* fall through */ > > > ------------------------------------------------------------------------ > > -- Eric Pouech

2 2

winevdm.exe: double free or corruption (fasttop)
by Saulius Krasuckas 09 Apr '06

09 Apr '06

After renewing my wine and running 16-bit app I sometimes get such output in the console (when the app exits): $ ./wine /home/s2/cc/Program\ Files/winled/led2w.exe fixme:toolhelp:InterruptRegister16 (0000, 0x11d700ba), stub. fixme:toolhelp:InterruptUnRegister16 (0000), stub. *** glibc detected *** winevdm.exe: double free or corruption (fasttop): 0x7e014e98 *** ======= Backtrace: ========= /lib/libc.so.6[0x72ad7124] /lib/libc.so.6(__libc_free+0x77)[0x72ad765f] /usr/lib/libGL.so.1[0x67fd5d5e] ======= Memory map: ======== 00000000-00010000 --xp 00000000 00:00 0 00010000-00110000 rwxp 00010000 00:00 0 00110000-20000000 --xp 00110000 00:00 0 20000000-2001a000 r-xp 00000000 03:09 64133 /lib/ld-2.3.5.so (Full logs go attached) Now I wonder whether this is a bug in wine (winevdm possibly), in my glibc (v2.53.5-10.3 from FC4) or in libGL (brought by nVidia driver v1.0-8178-pkg2) ? Last time I got this is now, with last GIT commit date: Sat, 8 Apr 2006 18:03:59 +0000 (20:03 +0200). Any ideas how to determine the nature of bug?

1 0

Pixel Shader questions
by Ivan Gyurdiev 09 Apr '06

09 Apr '06

1) The following pixel shader opcodes appear to be implemented with fragment_ARB, yet they are marked REQUIRE_GLSL. This generates errors, and they are skipped. Is this intentional? D3DSIO_TEX (texld), D3DSIO_CND, D3DSIO_CMP. 2) D3DSIO_CMP appears incorrect according to info online - the Opengl CMP should check >0, while the DirectX checks >= 0. 3) Is there a point at storing the OpenGL code in this large table? I don't like how for half the codes wined3d attempts to map them 1:1 to an opengl code via this table, and for the other half it doesn't use this field at all [ because it can't, combinations are necessary ]. Why not get rid of the field completely? 4) Wined3d likes to print out comment tokens as a FIXME - can this be downgraded to a TRACE? 5) The d3d9 pixel shader relay says (Disabled) - this is misleading, the shaders are enabled. ========== I want to figure out why HL2 doesn't work - enabling the codes above does not seem to help (but looking at the generated shader output, it makes make more sense). HL2 has severe texturing, lighting, and sound problems with hardware shaders (and it's slow and unusable with the software ones).

2 3

more Recommended Packages for Debian
by Corey McClymonds 09 Apr '06

09 Apr '06

Hi, For the recommended packages wiki page, there are a couple of packages that aren't included in that: libicu34-dev libssl-dev giflib3g-dev libxxf86vm-dev libxxf86dga-dev. Relatedly, I can't compile, because I get an error about openGL: checking for glXCreateContext in -lGL... no configure: error: /usr/X11R6/lib/libGL.a is present on your system. This prevents linking to OpenGL. Delete the file and restart configure. Apparently it only shows this if glXCreateContext isn't found, yet xlibmesa-gl-dev has this function. How can I get configure to see it? Corey

1 0

Repeatable BadAtom, valgrind errors; find in notepad broken
by Dan Kegel 09 Apr '06

09 Apr '06

Well, I switched to Dapper Drake Flight 6, but the X errors persist. I can reproduce them trivially tonight on my laptop by hitting Find in wine's Notepad (I was trying to reproduce http://bugs.winehq.org/show_bug.cgi?id=1614). The errors look like X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 and now that winedbg is working again (yay), setting WINEDEBUG=+synchronous generates a good backtrace: 3 0x7f231cea _XError+0xf4 in libx11.so.6 (0x7f231cea) 4 0x7f23229e _XReply+0x185 in libx11.so.6 (0x7f23229e) 5 0x7f212c7d XGetAtomNames+0x131 in libx11.so.6 (0x7f212c7d) 6 0x7f315cfd X11DRV_CLIPBOARD_InsertSelectionProperties+0x17b(properties=<register not in topmost frame>) [/home/dank/wine/dlls/x11drv/clipboard.c:1788] in winex11 (0x7f315cfd) 7 0x7f3182ae X11DRV_CLIPBOARD_UpdateCache+0x3e6(lpcbinfo=<register not in topmost frame>) [/home/dank/wine/dlls/x11drv/clipboard.c:1911] in winex11 (0x7f3182ae) 8 0x7f3187a8 X11DRV_IsClipboardFormatAvailable+0x28(wFormat=0x1) [/home/dank/wine/dlls/x11drv/clipboard.c:2498] in winex11 (0x7f3187a8) 9 0x7f6c30f9 IsClipboardFormatAvailable+0x25(wFormat=0x1) [/home/dank/wine/dlls/user/clipboard.c:583] in user32 (0x7f6c30f9) 10 0x7fb84488 NOTEPAD_WndProc+0x2e8(hWnd=0x70124, msg=0x117, wParam=0x1e0, lParam=0x2) [/home/dank/wine/programs/notepad/main.c:160] in notepad (0x7fb84488) Turning on +clipboard makes the error go away, so I guess it's a Heisenbug. (Doesn't make find work, though; that's http://bugs.winehq.org/show_bug.cgi?id=1614 ) Running notepad.exe.so under valgrind reveals a few suspicious lines: ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x205EE469: SELECTOR_SetEntries (../../include/wine/library.h:130) ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x20604A9C: WOWTHUNK_Init (../../include/wine/library.h:130) ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x219EFD36: XcursorImageHash (in /usr/lib/libXcursor.so.1.0.2) ==22697== ==22697== Syscall param write(buf) points to uninitialised byte(s) ==22697== at 0x20000772: (within /lib/ld-2.3.6.so) ==22697== Address 0x213A4EF2 is on thread 1's stack ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x200235AD: wine_ldt_get_entry (../../include/wine/library.h:130) ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x2180CC68: X11DRV_KeymapNotify (keyboard.c:1275) ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x2180CC9E: X11DRV_KeymapNotify (keyboard.c:1278) None of the above happen after the ^F, though, so while they look bad, they might not have anything to do with notepad's problems. Time to sleep. I'm posting these notes for my own use later, and in case anyone feels like checking up on any of the BadAtom, valgrind, or 'find in notepad' errors. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 2

Re: Winecfg - ESPERANTO Language Support
by Alexandre Julliard 08 Apr '06

08 Apr '06

f_sophia <f_sophia(a)libero.it> writes: > Hi WINE-Folks... > > Change Log. > autor: Antonio Codazzi > e-mail: f_sophia(a)libero.it > Content: > /programs/winecfg/Eo.rc (Esperanto Language) > New language support Several of your patches don't compile. Please make sure to test against the current tree before submitting. -- Alexandre Julliard julliard(a)winehq.org

1 0

dlls/d3d9/volume.c regression
by Gerald Pfeifer 08 Apr '06

08 Apr '06

The following patch revision 1.20 date: 2006-04-07 15:06:58 +0200; author: julliard; state: Exp; lines: +1 -1 Stefan Dösinger <stefandoesinger(a)gmx.at> wined3d: Add WINED3DBOX to wined3d_types.h. has one, and only one, effect as far as I can tell: it adds a new compiler warning volume.c: In function 'IDirect3DVolume9Impl_LockBox': volume.c:175: warning: passing argument 2 of 'This->wineD3DVolume->lpVtbl->LockBox' from incompatible pointer type both on SUSE Linux 10.0 using GCC 4.0 as well as FreeBSD 5.4 using GCC 3.4. (dlls/d3d9/volumetexture.c has exactly the same problem: 'IDirect3DVolumeTexture9Impl_LockBox': volumetexture.c:191: warning: passing argument 3 of 'This->wineD3DVolumeTexture->lpVtbl->LockBox' from incompatible pointer type.) Would you mind fixing these? Thanks, Gerald

2 1

Coverity first-day results
by Mike Hearn 08 Apr '06

08 Apr '06

Last nights run eliminated 31 defects as flagged by the scanner and added a new REVERSE_INULL in dlls/secur32/tests/main.c. We're now down from 833 to 803. That file hasn't changed since February so it appears the scanner is either still working its way through the code or Coverity are adapting it as it goes so it can cover more of the codebase. If you look at the number of functions scanned in each report it constantly goes up, so it does seem that right now its coverage of the codebase is incomplete. Nonetheless, wiping out 30 in the space of 2 days is not bad going at all! Congrats everybody! Of course a few of these bugs are quite trivial or would be hardly ever encountered, but it's still nice to fix them so they don't clutter up the reports with noise and it's easier to spot the more important ones. thanks -mike

1 0

Re: [coverity] fix dereferencing a potential NULL pointer.
by Dimi Paun 08 Apr '06

08 Apr '06

On Sat, 2006-04-08 at 12:48 +0200, Rein Klazes wrote: > dlls/user : menu.c > Fix dereferencing a potential NULL pointer. This patch seems to be doing more than avoiding a NULL dereference. Also, can you also mention which pointer can be NULL? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

← Newer
1
...
23
24
25
26
27
28
29
...
34
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2006