wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

Patch submission
by n1iic Jason Greene 10 Apr '06

10 Apr '06

Greetings. I am a new Linux user, and I would like to request a patch addition to add functionality for a game. The information can be found at http://wiki.minegoboom.com/index.php/Running_Continuum_under_Wine I think for the people that want to learn Linux, applying the patch is a great exercise, like I found. Unfortunately, it is long and involved and might scare off those that have less confidence or don't have a guru handy, but still want to try. I originally sent this to the wine-patches list and the owner recommended that I send it here. Thanks Jason

3 2

Wine tarball patched with DDraw/DX7 over WineD3D patches
by Alexander Nicolaysen Sørnes 10 Apr '06

10 Apr '06

I have made a tarball with Wine CVS patched with the DirectDraw/DirectX 7 over WineD3D patches so it is easier to test/use. Feel free to link to the page. http://www.thehandofagony.com/alex/wine-wd3dp/ The patches fixes the redrawing problems for Warlords Battlecry, and the animations in Stronghold: Crusader are now smooth instead of jerky. Screenshot from Warlords Battlecry http://appdb.winehq.org/screenshots.php?appId=2686&versionId=3913 Regards, Alexander N. Sørnes

1 0

Re: Missing fonts
by Alexander N. Sørnes 10 Apr '06

10 Apr '06

Vitaliy Margolen skrev: >Sunday, April 9, 2006, 4:15:22 PM, Alexander N. Sørnes wrote: > > > >I'm sorry, but are you reading this mailing list at all? To sum it up: >1. You need fontforge. >2. You need _working_ fontforge. >3. You need Wine's fonts made with working fontforge. > >Same thing for freetype. > >Vitaliy > > First of all, I am very sorry if I sent a message in ignorance. But wasn't the FontForge stuff introduced before 0.9.11? Compiling and running 0.9.11 works fine, but doing the same for CVS does not. > > > > >

1 0

Wine tarball patched with DDraw/DX7 over WineD3D patches
by "Alexander N. Sørnes" 10 Apr '06

10 Apr '06

1 0

Wine tarball patched with DDraw/DX7 over WineD3D patches
by "Alexander N. Sørnes" 10 Apr '06

10 Apr '06

1 0

DDraw over WineD3D - Indexed colour visuals
by Adam Luchjenbroers 10 Apr '06

10 Apr '06

I've been using and tracking Stefan Dossinger's work re: DDraw over WineD3D and decided try and find out if IWineD3DSurface was far enough along to be able to be used in place of IWineX11Surface for 2d applications (Hopefully to eliminate depth conversion issues). Short answer, no. Long answer, Screen displays blank, trace log shows that glReadPixels at line 615 in wined3d\surface.c (LockRect) is failing with error GL_INVALID_OPERATION. Further investigation reveals that this is because glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably because an indexed colour visual was not available, and this buffer is connected directly to the screen). I figured I'd look to the people already familiar with the WineD3D\DDraw codebase before I tried to figure out my own solution. -- "Most people would rather die than think; in fact, they do so." - Bertrand Russell (1872 - 1970)

3 5

DirectX 7
by Dimi Paun 10 Apr '06

10 Apr '06

Hi folks, I am not up-to-date with the latest DirectX news, can someone please tell me if we have any support for DirectX 7? I have a screensaver (Marine Aquarium) that I would like to run, but it requires DirectX 7. Is there any trick to get it to run? Thanks! -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

4 4

Wine tarball patched with DDraw/DX7 over WineD3D patches
by "Alexander N. Sørnes" 09 Apr '06

09 Apr '06

1 0

[x11drv] Fix two clipboard bugs. Fixes BadAtom crash (bug 4601)
by Dan Kegel 09 Apr '06

09 Apr '06

[Is it safe to call intern_atoms() inside the event handler like this?] Changelog: Fix two clipboard problems that caused BadAtom crashes (bug 4601) and caused some clipboard formats to not be exported properly Patch also at http://kegel.com/wine/badatom3.patch if this gets mangled by gmail. dlls/x11drv/clipboard.c | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) Index: dlls/x11drv/clipboard.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/clipboard.c,v retrieving revision 1.51 diff -d -u -r1.51 clipboard.c --- dlls/x11drv/clipboard.c 22 Feb 2006 21:31:52 -0000 1.51 +++ dlls/x11drv/clipboard.c 9 Apr 2006 21:25:15 -0000 @@ -1784,6 +1784,10 @@ if (names) { wine_tsx11_lock(); + /* FIXME: we're at the mercy of the app sending the event here. + * Currently if they send a bogus atom, we will crash. + * We should handle BadAtom errors gracefully in this call. + */ XGetAtomNames( display, atoms, nb_atoms, names ); wine_tsx11_unlock(); for (i = 0; i < nb_atoms; i++) @@ -2790,6 +2794,13 @@ LPWINE_CLIPFORMAT lpFormats; LPWINE_CLIPDATA lpData; + /* Create X atoms for any clipboard types which don't have atoms yet. + * This avoids sending bogus zero atoms. + * Without this, copying might not have access to all clipboard types. + * FIXME: is it safe to call this here? + */ + intern_atoms(); + /* * Count the number of items we wish to expose as selection targets. */ @@ -2804,7 +2815,7 @@ while (lpFormats) { if ((lpFormats->wFormatID == lpData->wFormatID) && - lpFormats->lpDrvExportFunc) + lpFormats->lpDrvExportFunc && lpFormats->drvData) cTargets++; lpFormats = lpFormats->NextFormat; @@ -2832,8 +2843,15 @@ while (lpFormats) { if ((lpFormats->wFormatID == lpData->wFormatID) && - lpFormats->lpDrvExportFunc) - targets[i++] = lpFormats->drvData; + lpFormats->lpDrvExportFunc) { + /* Don't send zeroes, lest receiver choke on XGetAtomName() */ + if (lpFormats->drvData) { + assert(i < cTargets); + targets[i++] = lpFormats->drvData; + } else { + WARN("bug: ignoring zero atom...\n"); + } + } lpFormats = lpFormats->NextFormat; } @@ -2841,6 +2859,7 @@ lpData = lpData->NextData; } while (lpData != ClipData); + assert(i == cTargets); wine_tsx11_lock(); @@ -2849,7 +2868,10 @@ unsigned int i; for ( i = 0; i < cTargets; i++) { - if (targets[i]) + /* intern_atoms() should make these nonzero. + * We checked before adding them to the array, just to be safe. + */ + assert(targets[i]); { char *itemFmtName = XGetAtomName(display, targets[i]); TRACE("\tAtom# %d: Property %ld Type %s\n", i, targets[i], itemFmtName); -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Coverity doing scans of Wine codebase!
by Dan Kegel 09 Apr '06

09 Apr '06

See http://scan.coverity.com/ They say they've found 830 potential bugs - that's quite a few. I haven't seen 'em yet, still waiting for my registration to come through. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

15 27

Wine as Windows Terminal Server?
by Samuel Hunt 09 Apr '06

09 Apr '06

Thought for you all..... Would it be possible to use Wine with a few extra bits to make a kind of Windows Terminal Server? So you login via VNC, and the Wine system prompts you for a username and password, which it authenticates. It then loads up a "desktop", with a fake "Start" menu, that you have things similar to a normal start menu, but more appropriate to a terminal server environment. You then run your programs, but all the I/O is to/from the remote client, and each session is independent of each other, so there can be lots of different clients with different permissions (so admin may have full access to all of the drive, but users have various bits of their "hard drive" read-only and things like that). Would seem to make Wine very useful if that could be done. Then VNC clients simply see a "Windows" desktop, and can do what they want, but all the back-end is Wine and Linux. Sam

3 2

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

wine-patches archive attachments have strange mime type?
by Dan Kegel 08 Apr '06

08 Apr '06

When I'm looking at the wine-patches archives, e.g. at http://winehq.org/pipermail/wine-patches/2006-April/025521.html and the patch is an attachment, the archive's link to the attachment, e.g. http://www.winehq.org/pipermail/wine-patches/attachments/20060408/64e34006/… can't be displayed by my copy of Firefox; it doesn't recognize the DIFF or PATCH mime types. I tried adding them in /etc/mime.types, and I tried looking for a way to set them in Firefox, but no joy. Should the server be serving these up as mime type text/plain? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Dogfood gone runny: fonts awful in firefox
by Dan Kegel 08 Apr '06

08 Apr '06

Seems like the recent font patches have caused trouble in both Firefox. In Firefox, I have to install corefonts for text to be legible at all lately. Is this expected? -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 2

Re: Makefile.in: Fix broken ctags/etags-targets
by Alexandre Julliard 08 Apr '06

08 Apr '06

Detlef Riekenberg <wine.dev(a)web.de> writes: > "make etags" and "make ctags" are broken. What's broken about them? -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: PATCH: makedep warning
by Alexandre Julliard 08 Apr '06

08 Apr '06

Marcus Meissner <marcus(a)jet.franken.de> writes: > glibc 2.4 + FS=2 makes it warn on ftruncate result > handling. The result cannot be -1 actually, but > check for it anyway. > > Ciao, Marcus > > Changelog: > Check result of ftruncate(). Please don't do that, it's useless. -- Alexandre Julliard julliard(a)winehq.org

1 0

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