April 2006 - Wine-Devel - list.winehq.org

Wine as Windows Terminal Server?
by Samuel Hunt April 9, 2006

April 9, 2006

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 April 9, 2006

April 9, 2006

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 April 9, 2006

April 9, 2006

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 April 9, 2006

April 9, 2006

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 April 9, 2006

April 9, 2006

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 April 9, 2006

April 9, 2006

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 April 9, 2006

April 9, 2006

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 April 8, 2006

April 8, 2006

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 April 8, 2006

April 8, 2006

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 April 8, 2006

April 8, 2006

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 April 8, 2006

April 8, 2006

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 April 8, 2006

April 8, 2006

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 April 8, 2006

April 8, 2006

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 April 8, 2006

April 8, 2006

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 April 8, 2006

April 8, 2006

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

msvcrt: handle inheritance problem
by qingdoa daoo April 8, 2006

April 8, 2006

HI all, Recently I have been trying to improve support for some MinGW based IDEs without native msvcrt. Now I am dealing with a problem with standard io handle redirection which prevents output from gcc tools from being piped to IDE message windows. I have been able to find that the problem is related to this patch on dlls/msvcrt/file.c http://cvs.winehq.org/cvsweb/wine/dlls/msvcrt/file.c.diff?r1=1.59&r2=1.60&f… It has a one line changlog saying: Duplicate stdin/stdout handles to avoid closing them when library is unloaded. If I revert file.c to pre-patch state, redirection works fine. But am not sure if there will be unexpected consequences. So I searched the wine-patch and wine-devel archives but didn't find the patch or any discussion about it. Could someone explain what exactly that changelog line means? A simple test program ------------------------------------------------------------------------ #include "stdio.h" #include "process.h" int main(int argc, char* argv[]) { if( argc == 1 ) { char *argv2[] = { argv[0], "foo", NULL }; _spawnv(_P_NOWAIT, argv[0], argv2); } else { puts("This won't print with builtin msvcrt"); } return 0; } --------------------------------- Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice.

1 0

FFXI Winsock Question
by Andres Mejia April 8, 2006

April 8, 2006

I'm having a problem with staying connected while logged in to the PlayOnline service of FFXI. The only debug message I keep finding is a warning that goes "warn:winsock: WSAErrno errno 4 (Interrupted system call)." I already submitted a bug for this but I'm wondering if there was anymore I could do. What I'm asking is, have I done enough or is there something more that I can do to help with fixing this bug?

1 0

NtProtectVirtualMemory
by Segin April 7, 2006

April 7, 2006

Could someone clue me in to just what this means and why it is: err:virtual:NtProtectVirtualMemory Unsupported on other process A quick Google comes up that function is undocumented, so I don't have much info on it. From the wine source: if (!is_current_process( process )) { ERR("Unsupported on other process\n"); return STATUS_ACCESS_DENIED; } And that's self explanitory, but why is it "Unsupported on other process"?

5 8

Re: WineD3D: Allow the inclusion of the wined3d headers when the ddraw headers are included
by Alexandre Julliard April 7, 2006

April 7, 2006

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: >> Alexandre, if you think >> that it should be in the wined3d headers, you can add >> #define MAKEFOURCC(a,b,c,d) ((a << 0) | (b << 8) | (c << 16) | (d << 24)) >> in line 169 in wined3d_interface.h, or ask me to send a patch for that. > Forget about that, I forgot that wined3d_types is included before that line. > Attached is a patch which creates WINEMAKEFOURCC and uses this. Windows has a MAKEFOURCC in ddraw.h too, probably you should use that instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

server: Fix for possible desktop variable being NULL when set_process_default_desktop is called
by Dan Kegel April 7, 2006

April 7, 2006

Mike Hearn wrote: >I'm not really convinced a static >analysis can catch things that we "know" cannot happen (eg it'd be a >violation of the X protocol or something) and so rely on them without >explicit checks. To be secure, I think we have to handle X protocol violations, too. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Compiling wine 0.9.11 under solaris 10
by Chiaki April 7, 2006

April 7, 2006

I am trying to build wine-0.9.11 on a solaris express system (nevada b29). But at the end of compilation, I got link errors in a couple places. (messages are given below.) I followed the guidance at http://www.blastwave.org/wine/winemaking.html I had not known the tips mentioned at http://wiki.jswindle.com/index.php/Installing_Wine#Solaris before I tried compilation, Because I didn't know, instead of disabling some macros as suggested in the above URL, I hacked the source files so that the previously ignored files were compiled under Solaris 10 (or Solaris 11 beta). (I listed some of these into a mail list mentioned at blastware web page [solaris package repository] http://lists.blastwave.org/pipermail/users/2006-April/thread.html when I was tinkering with 0.9.10. The changes are basically the same for the case of 0.9.11 with a few additions now that I have configured 0.9.11 in a slightly different manner from the way 0.9.10 was configured. And the link errors I saw have not changed between 0.9.10 and 0.9.11) Anyway, at the end of compilation, I got link errors in a couple places. ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status These seem to be due to versioning(?) of read/write system call symbols or something. (SUNW seems to be symbol used by SUN to mark symbols coming from their libraries, etc.. It is market symbol for Sun Microsystems. Most of Sun-supplied `packages' for solaris is named like SUNWxyz to denote that they are coming from Sun instead of 3rd parties.) Have anybody seen these link problems before? Are there any workarounds? Or am I using incorrect ld/gas, etc? Tool chain information. $ uname -a SunOS solaris-nv-28-home 5.11 snv_28 i86pc i386 i86pc $ which gcc /usr/sfw/bin/gcc bash-3.00$ gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (I have replaced /usr/ccs/bin/ld invoked with the above to be gnu ld instead of the original sun ld.) bash-3.00$ /usr/ccs/bin/ld --version GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. bash-3.00$ The eerors at this stage are only seen for two programs namely wine-kthread and wine-server at this moment. The entire log for the last remaining errors follows here. (Line folding is done by the mailer here, sorry about this.) cd /home/ishikawa/local-src/wine-sources/wine-0.9.11/ bash-3.00$ make -k gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wine-kthread -Wl,--export -dynamic -Wl,--section-start,.interp=0x7bf00400 -Wl,--rpath,\$ORIGIN/`../tools /relpath /usr/local/bin /usr/local/lib` kthread.o main.o -L../libs/wine -lwine -L../libs/port -lwine_port ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/lo ader *** Error code 1 The following command caused the error: cd loader && make `libdinput.def.a' is up to date. ../../tools/winegcc/winegcc -B../../tools/winebuild -mwindows curses.o dialog .o registry.o user.o wineconsole.o wineconsole_res.res -o wineconsole.exe. so -Wl,--rpath,\$ORIGIN/`../../tools/relpath /usr/local/lib/wine /usr/local/li b` -L../../dlls -lcomctl32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -lntdll -L.. /../libs -lwine -L../../libs/port -lwine_port -lrt -lthread -lsocket -lnsl - lcurses -Wb,-dcomctl32 -Wb,-duser32 -Wb,-dgdi32 gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wineserver -Wl,--rpath,\$ ORIGIN/`../tools/relpath /usr/local/bin /usr/local/lib` atom.o change.o clas s.o clipboard.o console.o context_alpha.o context_i386.o context_powerpc. o context_sparc.o context_x86_64.o debugger.o directory.o event.o fd.o file.o handle.o hook.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o ptrace.o queue.o region.o registry.o request.o sem aphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o sunptrace.o -L. ./libs/wine -lwine -L../libs/unicode -lwine_unicode -L../libs/port -lwine_port -lrt -lthread -lsocket -lnsl ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/se rver *** Error code 1 The following command caused the error: cd server && make make: Warning: Target `all' not remade because of errors bash-3.00$ TIA -- int main(void){int j=2006;/*(c)2006 cishikawa. */ char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\""; char *i ="d>qtCIuqivb,gCwe\np(a).ietCIuqi\"tqkvv is>dnamz"; while(*i)((j+=(int)strchr(t,*i++)-(int)t),(j%=sizeof t-1), (putchar(t[j])));return 0;}/* under GPL */

1 0

Re: [dsound] set default primary buffer sample rate and bits per sample
by Alexandre Julliard April 7, 2006

April 7, 2006

Robert Reif <reif(a)earthlink.net> writes: > Programs that are written specifically for 2000 and xp don't > bother to set the primary buffer format because it's a noop. However > wine is patterned after win9x and DirectX 7 or > earlier which has a real primary buffer and expects the > program to change the primary buffer format if necessary. > > This patch provides a way to change the primary buffer format > from 22050x8 to an application specific value or a system wide > value for programs that don't. Shouldn't we make it work the win2k way then, instead of requiring users to configure things manually? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: server: Fix for possible desktop variable being NULL when set_process_default_desktop is called
by Alexandre Julliard April 7, 2006

April 7, 2006

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > The desktop variable could be NULL when set_process_default_desktop is > called, so check for this. (Found by Coverity). I don't see how this could happen. Did I miss something? -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: buffer check in comdlg
by Robert Shearman April 7, 2006

April 7, 2006

Aric Stewart wrote: > if(fodInfos->unicode) > { > LPOPENFILENAMEW ofn = fodInfos->ofnInfos; >- strcpyW( ofn->lpstrFile, lpstrPathSpec); >- memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR) ); >+ if (nSizePath+sizeUsed > ofn->nMaxFile) >+ { >+ *((WORD*)ofn->lpstrFile)=nSizePath+sizeUsed; >+ FILEDLG95_Clean(hwnd); >+ EndDialog(hwnd,FALSE); >+ COMDLG32_SetCommDlgExtendedError(FNERR_BUFFERTOOSMALL); >+ return FALSE; >+ } >+ else >+ { >+ strcpyW( ofn->lpstrFile, lpstrPathSpec); >+ memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR) ); >+ } > } > > This formatting doesn't look at all consistent, either with itself or the other code there. -- Rob Shearman

2 1

WineD3D: Add a WINEMAKEFOURCC macro
by Stefan Dösinger April 7, 2006

April 7, 2006

Hello, Alexandre, if you think > that it should be in the wined3d headers, you can add > #define MAKEFOURCC(a,b,c,d) ((a << 0) | (b << 8) | (c << 16) | (d << 24)) > in line 169 in wined3d_interface.h, or ask me to send a patch for that. Forget about that, I forgot that wined3d_types is included before that line. Attached is a patch which creates WINEMAKEFOURCC and uses this. Changelog: Stefan Dösinger: Add a WINEMAKEFOURCC macro to wined3d_types.h

1 0

Re: advpack: Rewrite get_parameter to be able to handle an empty parameter
by James Hawkins April 7, 2006

April 7, 2006

On 4/7/06, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Changelog: > * Rewrite get_parameter to be able to handle an empty parameter. > blah Ignore this, because I sent too much in one patch. -- James Hawkins

1 0

new to wine, Guild Wars don't display correctly
by BONNEL Christophe April 7, 2006

April 7, 2006

3 6

Re: msi: Use a debug channel to turn on transform debugging. (Coverity)
by Alexandre Julliard April 7, 2006

April 7, 2006

Mike McCormack <mike(a)codeweavers.com> writes: > --- a/dlls/msi/table.c > +++ b/dlls/msi/table.c > @@ -1604,13 +1604,12 @@ static MSIRECORD *msi_get_transform_reco > USHORT mask = *rawdata++; > MSICOLUMNINFO *columns = tv->columns; > MSIRECORD *rec; > - const int debug_transform = 0; > > rec = MSI_CreateRecord( tv->num_cols ); > if( !rec ) > return rec; > > - if( debug_transform ) MESSAGE("row -> "); > + if( TRACE_ON(msidb) ) MESSAGE("row -> "); You should use TRACE instead of MESSAGE then, it will be a lot more readable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: x11drv: (bug 4685) properly handle VK_LMENU input (resend)
by Dmitry Timoshkov April 7, 2006

April 7, 2006

<tkho(a)ucla.edu> wrote: A couple of suggestions about coding style: > +struct transition_s { > + BYTE wVk; It would be more logical to use WORD for VK codes as everywhere else. > + BYTE before_state; > + BYTE _todo_wine; > +}; Same for _todo_wine, it should be BOOL. > + > +struct sendinput_test_s { > + WORD wVk; > + DWORD dwFlags; > + struct transition_s expected_transitions[MAXKEYEVENTS+1]; > + UINT expected_messages[MAXKEYMESSAGES+1]; > +} sendinput_test[] = { > + /* test ALT+F */ > + {VK_LMENU, 0, {{0x12, 0x00, 0}, {0xa4, 0x00, 0}, {0}}, {0x104, 0}}, > + {'F', 0, {{0x46, 0x00, 0}, {0}}, {0x104, 0x106, 0x112, 0}}, > + {'F', KEYEVENTF_KEYUP, {{0x46, 0x80, 0}, {0}}, {0x105, 0}}, > + {VK_LMENU, KEYEVENTF_KEYUP, {{0x12, 0x80, 0}, {0xa4, 0x80, 0}, {0}}, > + {0x101, 0}}, Please use VK names and symbolic message names in the above arrays to make them more readable. > /*********************************************************************** > * X11DRV_send_keyboard_input > @@ -1128,14 +1141,16 @@ > { > message = WM_KEYUP; > if ((key_state_table[VK_MENU] & 0x80) && > - ((wVk == VK_MENU) || (wVk == VK_CONTROL) || !(key_state_table[VK_CONTROL] & 0x80))) > + ((VkStripLR(wVk) == VK_MENU) || (VkStripLR(wVk) == VK_CONTROL) > + || !(key_state_table[VK_CONTROL] & 0x80))) > { > if( TrackSysKey == VK_MENU || /* <ALT>-down/<ALT>-up sequence */ > - (wVk != VK_MENU)) /* <ALT>-down...<something else>-up */ > + (VkStripLR(wVk) != VK_MENU)) /* <ALT>-down...<something else>-up */ > message = WM_SYSKEYUP; > TrackSysKey = 0; > } > key_state_table[wVk] &= ~0x80; > + key_state_table[VkStripLR(wVk)] &= ~0x80; > keylp.lp1.previous = 1; > keylp.lp1.transition = 1; > } > @@ -1145,12 +1160,13 @@ > keylp.lp1.transition = 0; > if (!(key_state_table[wVk] & 0x80)) key_state_table[wVk] ^= 0x01; > key_state_table[wVk] |= 0xc0; > + key_state_table[VkStripLR(wVk)] |= 0xc0; > > message = WM_KEYDOWN; > if ((key_state_table[VK_MENU] & 0x80) && !(key_state_table[VK_CONTROL] & 0x80)) > { > message = WM_SYSKEYDOWN; > - TrackSysKey = wVk; > + TrackSysKey = VkStripLR(wVk); It would be much simpler to call VkStripLR() only once and use the result for further processing. -- Dmitry.

1 0

Compiling wine 0.9.11 under solaris 10
by Chiaki April 7, 2006

April 7, 2006

I am trying to build wine-0.9.11 on a solaris express system (nevada b29). But the end of compilation, I got link errors in a couple places. (messages are given below.) I followed the guidance at http://www.blastwave.org/wine/winemaking.html I had not known the tips mentioned at http://wiki.jswindle.com/index.php/Installing_Wine#Solaris before I tried compilation, Because I didn't know, instead of disabling some macros as suggested in the above URL, I hacked the source files so that the previously ignored files were compiled under Solaris 10 (or Solaris 11 beta). (I listed some of these into a mail list mentioned at blastware web page [solaris package repository] http://lists.blastwave.org/pipermail/users/2006-April/thread.html when I was tinkering with 0.9.10. The changes are basically the same for the case of 0.9.11 with a few additions now that I have configured 0.9.11 in a slightly different manner as was done for 0.9.10 mentioned in the above link. And the link errors I saw have not changed between 0.9.10 and 0.9.11) Anyway, at the end of compilation, I got link errors in a couple places. ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status These seem to be due to versioning(?) of read/write system call symbols or something. (SUNW seems to be symbol used by SUN to mark symbols coming from their libraries, etc.. It is market symbol for Sun Microsystems. Most of Sun-supplied `packages' for solaris is named like SUNWxyz to denote that they are coming from Sun instead of 3rd parties.) Have anybody seen these link problems before? Are there any workarounds? Or am I using incorrect ld/gas, etc? Tool chain information. $ uname -a SunOS solaris-nv-28-home 5.11 snv_28 i86pc i386 i86pc $ which gcc /usr/sfw/bin/gcc bash-3.00$ gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (I have replaced /usr/ccs/bin/ld invoked with the above to be gnu ld instead of the original sun ld.) bash-3.00$ /usr/ccs/bin/ld --version GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. bash-3.00$ There are only seen for two programs namely wine-kthread and wine-server at this moment. The entire log for the last remaining erros follows here. (Line folding is done by the mailer here, sorry about this.) cd /home/ishikawa/local-src/wine-sources/wine-0.9.11/ bash-3.00$ make -k gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wine-kthread -Wl,--export -dynamic -Wl,--section-start,.interp=0x7bf00400 -Wl,--rpath,\$ORIGIN/`../tools /relpath /usr/local/bin /usr/local/lib` kthread.o main.o -L../libs/wine -lwine -L../libs/port -lwine_port ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/lo ader *** Error code 1 The following command caused the error: cd loader && make `libdinput.def.a' is up to date. ../../tools/winegcc/winegcc -B../../tools/winebuild -mwindows curses.o dialog .o registry.o user.o wineconsole.o wineconsole_res.res -o wineconsole.exe. so -Wl,--rpath,\$ORIGIN/`../../tools/relpath /usr/local/lib/wine /usr/local/li b` -L../../dlls -lcomctl32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -lntdll -L.. /../libs -lwine -L../../libs/port -lwine_port -lrt -lthread -lsocket -lnsl - lcurses -Wb,-dcomctl32 -Wb,-duser32 -Wb,-dgdi32 gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wineserver -Wl,--rpath,\$ ORIGIN/`../tools/relpath /usr/local/bin /usr/local/lib` atom.o change.o clas s.o clipboard.o console.o context_alpha.o context_i386.o context_powerpc. o context_sparc.o context_x86_64.o debugger.o directory.o event.o fd.o file.o handle.o hook.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o ptrace.o queue.o region.o registry.o request.o sem aphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o sunptrace.o -L. ./libs/wine -lwine -L../libs/unicode -lwine_unicode -L../libs/port -lwine_port -lrt -lthread -lsocket -lnsl ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/se rver *** Error code 1 The following command caused the error: cd server && make make: Warning: Target `all' not remade because of errors bash-3.00$ TIA -- int main(void){int j=2006;/*(c)2006 cishikawa. */ char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\""; char *i ="d>qtCIuqivb,gCwe\np(a).ietCIuqi\"tqkvv is>dnamz"; while(*i)((j+=(int)strchr(t,*i++)-(int)t),(j%=sizeof t-1), (putchar(t[j])));return 0;}/* under GPL */

1 0

Coverity Open Source Defect Scan of Wine
by Ben Chelf April 7, 2006

April 7, 2006

Hello Wine Developers, As some of you may have heard, last month Coverity set up http://scan.coverity.com as a site dedicated to scanning open source projects for defects. In just 1 month, over 4500 defects have been examined by various open source developers, and from what we can tell, it seems that there have been over 2500 patches to the scanned code bases! Due to popular request, I’m happy to announce that we’ve added Wine to the list of projects scanned on the site. For those of you not familiar with "scan" yet and by way of introduction ... I'm the CTO of Coverity, Inc., a company that has technology that performs static source code analysis to look for defects in code. You may have heard of us or of our technology from its days at Stanford (the "Stanford Checker"). The reason I'm writing is because we have set up a framework internally to continually scan open source projects and provide the results of our analysis back to the developers of those projects. To see the results of the project, check out: http://scan.coverity.com My belief is that we (Coverity) must reach out to the developers of these packages (you) in order to make progress in actually fixing the defects that we happen to find, so this is my first step in that mission. Of course, I think Coverity technology is great, but I want to hear what you think and that's why I worked with folks at Coverity to put this infrastructure in place. The process is simple -- it checks out your code each night from your repository and scans it so you can always see the latest results. Right now, we're guarding access to the actual defects that we report for a couple of reasons: (1) We think that you, as developers of Wine, should have the chance to look at the defects we find to patch them before random other folks get to see what we found and (2) From a support perspective, we want to make sure that we have the appropriate time to engage with those who want to use the results to fix the code. Because of this second point, I'd ask that if you are interested in really digging into the results a bit further for your project, please have a couple of core maintainers and/or developers reach out to us to request access. As this is a new process for us and still involves a small number of packages, I want to make sure that I personally can be involved with the activity that is generated from this effort. So I'm basically asking for people who want to play around with some cool new technology to help make source code better. If this interests you, please feel free to register on our site or email me directly. And of course, if there are other packages you care about that aren't currently on the list, I want to know about those too. If this is the wrong list, my sincerest apologies and please let me know where would be a more appropriate forum for this type of message. Many thanks for reading this far... -ben Ben Chelf Chief Technology Officer Coverity, Inc.

2 1

Building in Unicode mode
by Sergio April 6, 2006

April 6, 2006

Hi, I am trying to compile something that needs to be compiled defining UNICODE and _UNICODE but I am getting this error: In file included from plugins/yapp/../../include/m_database.h:67, from plugins/yapp/stdafx.h:39, from plugins/yapp/options.cpp:1: /usr/include/wine/windows/tchar.h:27:2: error: #error You must use msvcrt when building in Unicode/MBCS mode I tried defining __WINE_USE_MSVCRT but it did not help. Does anyone have any idea of how to solve this problem? Thank you in advance. Sergio.

1 0

Re: [coverity] Don't close uninitialized handle on VXD error path
by Andrey Turkin April 6, 2006

April 6, 2006

I thought INVALID_HANDLE_VALUE==-1 and not 0. Moreover, I can't see any code path leading to ERR where handle is allocated (or assigned to) at all so I think there is no need to close it. Mike Hearn wrote: > Mike Hearn <mike(a)plan99.net> > Don't close uninitialized handle on VXD error path > > diff --git a/dlls/kernel/vxd.c b/dlls/kernel/vxd.c > index 5d16684..2a004a0 100644 > --- a/dlls/kernel/vxd.c > +++ b/dlls/kernel/vxd.c > @@ -179,7 +179,7 @@ HANDLE VXD_Open( LPCWSTR filenameW, DWOR > { > static const WCHAR dotVxDW[] = {'.','v','x','d',0}; > int i; > - HANDLE handle; > + HANDLE handle = INVALID_HANDLE_VALUE; > HMODULE module; > WCHAR *p, name[16]; > > @@ -254,10 +254,14 @@ HANDLE VXD_Open( LPCWSTR filenameW, DWOR > } > > ERR("too many open VxD modules, please report\n" ); > - CloseHandle( handle ); > + > + if (handle) > + { > + CloseHandle( handle ); > + handle = 0; > + } > FreeLibrary( module ); > - handle = 0; > - > + > done: > RtlLeaveCriticalSection( &vxd_section ); > if (!DuplicateHandle( GetCurrentProcess(), handle, GetCurrentProcess(), &handle, 0, > > >

1 0

strange win in 2006 SourceForge.net Community Choice Awards
by Marcus Meissner April 6, 2006

April 6, 2006

Hi, The 2006 SourceForge.net Community Choice Awards have been announced ... and it seems the Desktop Winner is: "WINE ..... for Darwin and Mac OS X" Strangely enough, our project directly does not appear to be listed at all in the "Desktop" category. Still considering whether to be sad or happy. I have now added us to the "Desktop environment" category. Ciao, Marcus

1 0

Re: fonts: Add the Won sign in place of the backslash for Korean fonts
by Huw D M Davies April 6, 2006

April 6, 2006

On Thu, Apr 06, 2006 at 12:45:01PM +0100, Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > fonts: Add the Won Sign in place of the backslash for Korean fonts Actually could you ignore this for the moment? Dmitry's got a patch that's about to arrive that'll clash with this, and this one is much easier to regenerate. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Invisible fonts regression
by Ivan Gyurdiev April 6, 2006

April 6, 2006

I am no longer able to see fonts in: - the GTA installer - for example on the intial screen ("What language to use?") - Steam (*with* Tahoma previously installed and working). When selecting menus fonts will flash quickly making the menu visible, and then disappear. In addition, when re-creating a new clean wine root, I also lose the ability to see fonts in winecfg. This is Wine 0.9.11 on Fedora Rawhide x86_64. There is no error output. The Steam problem was in the last release as well. What should I do to track down the problem?

5 8

SimCity 4 and hardware rendering -- Not working.
by Segin April 6, 2006

April 6, 2006

As usual, I went out and found something else to test. SimCity 4 Deluxe works, impeckably well, but it only does software rendering (which can literally bring your system to it's knees). I use a patched .exe cause the default one didn't work for me (and this one has a no-cd deal, plus is smaller). Anyways, when starting in Direct3D mode, it goes to a back window, but quickly flashes back to your desktop, with this debug: err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (0000000a) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (0000000b) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (0000000c) value : 0000000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANEMASK (0000000d) value : ffffffff ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTPIXEL (00000010) value : 00000001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (0000001e) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEANTIALIAS (00000028) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_RANGEFOGENABLE (00000030) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (0000008a) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_VERTEXBLEND (00000097) value : 00000000 ! It then resumes loading in software rendering.

3 2

WINE & Microsoft WGA
by Marcus Meissner April 6, 2006

April 6, 2006

Hi, Just found by random websearch... http://www.microsoft.com/genuine/downloads/FAQ.aspx?displaylang=en ... Q: Will systems running WINE pass WGA validation? A: Wine is an implementation of the Windows 3.x and Win32 APIs on top of X and Unix. When WGA validation detects WINE running on the system, it will notify users that they are running non-genuine Windows, and it will not allow genuine Windows downloads for that system. Users of WINE should consult the WINE community for WINE updates. It is important to note that WINE users, and other users of non-genuine Windows, can continue to download updates for most Microsoft applications from Microsoft application-specific sites, such as Office Update. Ciao, Marcus

3 2

EU CVS server is not up to date
by Berend Reitsma April 5, 2006

April 5, 2006

Hello, The EU CVS server is not up to date. The head of the Changelog is 1.110 while on cvs.winehq it is 1.111. $ cvs -n -d:pserver:cvs(a)rhlx01.fht-esslingen.de:/home/wine -q log ChangeLog | head RCS file: /home/wine/wine/ChangeLog,v Working file: ChangeLog head: 1.110 branch: locks: strict access list: symbolic names: Wine-0_9_10: 1.110 Wine-0_9_9: 1.109 Regards, Berend.

1 0

[opengl] Another possible fix for the BadMatch error
by Leon Freitag April 5, 2006

April 5, 2006

> The BadMatch in X_GLXCreateGLXPixmap is another problem.. here you > should get a BadMatch in X_GLXMakeCurrent. That's true, this patch should only fix the BadMatches in glXMakeCurrent. > BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a > patch but it was rejected. Well, try to resubmit it :) Or post it here, so that others could test it. Perhaps you could merge this one-liner into it and then resubmit it. Leon

2 5

Problem cloning wine repository with git...
by Scott Bambrough April 5, 2006

April 5, 2006

I'm having trouble cloning the wine repository. I attempt to clone it and never get any files. All I ever see is: $ git clone http://source.winehq.org/git/wine.git wine-git defaulting to local storage area I've followed the instructions found here: http://wiki.winehq.org/GitWine I've tried the following commands in an attempt to clone the wine repository: git clone git://source.winehq.org/git/wine.git wine-git git clone http://source.winehq.org/git/wine.git wine-git I'm using git version 1.0.4. I've also tried the latest version of the getwinegit.sh shell script with the same results. I've managed to use git to clone the kernel and git source trees, so git is working on my system. I started the clone of the wine source and let it run over lunch for an hour with no files. If anyone has an idea of what I'm doing wrong, or how to debug the problem I'd appreciate the help. I'm a git newbie. Cheers, Scott

2 2

Re: Alexandre Julliard : configure: Filter out garbage from arts-config --libs too.
by Marcus Meissner April 5, 2006

April 5, 2006

On Tue, Apr 04, 2006 at 05:37:44AM -0500, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 197a7d0422b2dd60009e405bc254ca616327fbf0 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=197a7d0422b2dd60009e405… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Apr 4 12:08:30 2006 +0200 > > configure: Filter out garbage from arts-config --libs too. > > --- > > configure | 9 ++++++++- > configure.ac | 9 ++++++++- > 2 files changed, 16 insertions(+), 2 deletions(-) > > diff --git a/configure b/configure > index 9bffafd..c825171 100755 > --- a/configure > +++ b/configure > @@ -10855,7 +10855,14 @@ then > -I*) ARTSC_CFLAGS="$ARTSC_CFLAGS $i";; > esac > done > - ARTSC_LIBS=`$ARTSCCONFIG --libs` > + ARTSC_LIBS="" > + for i in `$ARTSCCONFIG --libs` > + do > + case "$i" in > + -L/usr/lib|-L/usr/lib64) ;; > + -L*|-l*) ARTSC_LIBS="$ARTSC_LIBS $i";; > + esac > + done It also adds -L/opt/kde/lib64 for me, so this will likely not fully work. I would say we just do not configure arts and esd on 64->32 compiles. :/ Ciao, Marcus

2 4

Re: [PATCH] - rewrote toolhelp implementation only on top of ntdll functions
by Alexandre Julliard April 5, 2006

April 5, 2006

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > + l = min(ldr_mod[i].BaseDllName.Length, sizeof(mod->szModule) - sizeof(WCHAR)); > + memcpy(mod->szModule, ldr_mod[i].BaseDllName.Buffer, l); > + mod->szModule[l / sizeof(WCHAR)] = '\0'; > + l = min(ldr_mod[i].FullDllName.Length, sizeof(mod->szModule) - sizeof(WCHAR)); > + memcpy(mod->szExePath, ldr_mod[i].FullDllName.Buffer, l); This can't work, the dll name and path are in the address space of the target process. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wined3d/OpenGL question
by Jason Green April 5, 2006

April 5, 2006

I may be barking up the wrong tree here, but I'm trying to debug the cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in drawprim.c (line 1251). This is for Civilization 4 using both hardware vertex & pixel shaders. I've only noticed this error when it is passed GL_TRIANGLES with a large number of vertices. Here's a sample output with a little extra debugging info, and cleaned up a little: trace:d3d_draw:primitiveToGl TRIANGLES trace:d3d_draw:drawPrimitiveDrawStrided begin number of indices6144, number of vertices1156 trace:d3d_draw:drawPrimitiveDrawStrided end number of indices6144, number of vertices1156 ... trace:d3d_draw:drawPrimitiveDrawStrided Using pixel shader trace:d3d_draw:drawPrimitiveDrawStrided glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, pixelShader->prgId); call ok drawprim.c / 1846 trace:d3d_draw:drawPrimitiveDrawStrided glEnable(GL_FRAGMENT_PROGRAM_ARB); call ok drawprim.c / 1850 trace:d3d_draw:drawStridedFast (0x7fd98890) : glElements(4, 6144, 0, ...) fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from glDrawRangeElements @ drawprim.c / 1251 Often, a series of these errors will result in an unhandled exception in libglcore.so.1 (nvidia binary 8178 driver for a 6600GT, 2.6.16.1 kernel). I read up on the glDrawElements() function and it refered to the GetIntegerv() function for GL_MAX_ELEMENTS_VERTICES. When I call that function, it returns 4096, and the number of vertices that it's trying to pass is larger than that. I've tried doing a min() of the max and the actual # of vertices, but the results are the same. So, the question is: Could this be one of the causes of the graphical glitches I'm seeing? I can toy around with these functions all day, but I don't really understand them all that well. Does that routine need to be reworked to split up a D3DPT_TRIANGLELIST into multiple calls if the calculated number of vertices/indices is too high for the user's graphics card? Or, am I way off base thinking this has any bearing on my real issues? Thanks, Jason

3 4

d3d: unhandled texture formats
by Ivan Gyurdiev April 5, 2006

April 5, 2006

The F.E.A.R and BF2 demos crash immediately after complaining about: fixme:d3d:D3DFmtGetBpp Unhandled fmt(36,WINED3DFMT_A16B16G16R16) fixme:d3d:debug_d3dformat Unrecognized 81 D3DFORMAT! I have some native dlls installed, d3dx9_*.dll, mscoree.dll... that have no wine implementation. According to msdn: D3DFMT_A16B16G16R16 36 64-bit pixel format using 16 bits for each component. D3DFMT_L16 81 16-bit luminance only. The second one is missing from wined3d_private.h Both are missing from D3DFmtGetBpp. Also note that there's default handling in D3DFmtGetBpp that says: /* Guess at the highest value of the above */ and selects 4 bytes per pixel, but the highest value of the above is 8 - and it's used by D3DFMT_A16B16G16R16 - maybe that's why it crashes.

3 4

XVidMode is required for Gamma Control
by Jesse Allen April 5, 2006

April 5, 2006

I've found that XVidMode is required for gamma control, and that it defaults to off. There are two bug reports about gamma. One is Diablo 2 as it fails to run at all in D3D mode because of it (and with a cryptic error too). The other is the gamma slider fails to produce the effect. There are three ways to fix the problem: 1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this. 2) Make UseXVidMode default to "Y". 3) Tell people to set UseXVidMode manually. Let me know what any of you think is best. I'd prefer the first one so that I won't have people scratching their heads over what is going on. Though #2 might be more correct than #1. Something should be changed because it's silly that Diablo 2 cannot run by default. Jesse

7 16

Re: wine / fontforge regression
by hurtta+wine＠leija.mh.fmi.fi April 5, 2006

April 5, 2006

[ Charset UTF-8 unsupported, converting... ] > hurtta+wine(a)leija.mh.fmi.fi wrote: > > >http://www.winehq.org/pipermail/wine-devel/2006-April/046196.html > > > > > > > >>It's OK that most people don't have fontforge installed, that just > >>means that people who can't cope with compiling from source and can't > >>satisfy all the required dependencies to create a working binary > >>shouldn't do it. They need to use a prepackaged one from a > >>confidential source who knows what is needed and how to resolve the > >>dependencies. > >> > >> > > > > > >Perhaps because there is NO binary available on > >list of http://www.winehq.org/site/download > Then they can check their distributions source package tree (pkgsrc, > ports, etc.) or binary tree (which compliments pkgsrc, ports, etc. and > is compatable.) > > I mean, come on, can it be that hard to look in ports? If distribution is 4 years old, wine is also. Distributions works good enough, but 4 year old is little different. Or have you different opinion?

1 0

Re: richedit20: Implement EM_FORMATRANGE
by Phil Krylov April 4, 2006

April 4, 2006

On Tue, 4 Apr 2006 11:46:18 +1000 Troy Rollo <wine(a)troy.rollo.name> wrote: > + * *** Notes on tables *** > + * > + * The CHARRANGE structure passed in the FORMATRANGE structure is not > + * sufficient to deal with tables, where we would need information on the > + * start position for text in each column of the table. > + * > + * Testing on Windows NT shows that the Microsoft Rich Edit control gives > + * pathological results when there are tables in the document - both in edit > + * mode and for EM_FORMATRANGE. The Microsoft Rich Edit control uses the > + * table solely as a hint to where the paragraph should start. The table > + * does not expand to fit its text. Long paragraphs wrap when you hit the > + * right page margin and continue at the left page margin. This is only true for RichEdit 2.0 - later versions have better table support, while our current implementation is approximately at 2.0 level. -- Ph.

2 1

wine / fontforge regression
by hurtta+wine＠leija.mh.fmi.fi April 4, 2006

April 4, 2006

http://www.winehq.org/pipermail/wine-devel/2006-April/046196.html > It's OK that most people don't have fontforge installed, that just > means that people who can't cope with compiling from source and can't >satisfy all the required dependencies to create a working binary > shouldn't do it. They need to use a prepackaged one from a > confidential source who knows what is needed and how to resolve the > dependencies. Perhaps because there is NO binary available on list of http://www.winehq.org/site/download / Kari Hurtta

1 0

cvs help for bug #4541, Wine > 20050725 with FreeBSD 6.0
by Lee Parsons April 4, 2006

April 4, 2006

Hello I submitted the bug #4541 regarding running the application WinMDI on wine in FreeBSD 6.0: http://bugs.winehq.org/show_bug.cgi?id=4541 I have begun regression testing on this bug. I have determined that it seems to break on 20050921, as 0921 works and 0922 does not. However, I have been unable to cvs checkout any particular versions of wine for that day. For example, if I look at the wine-cvs archives for that day, and want to checkout for the patch submitted 05:20:20, I run the command: lparsons(a)r32_1600$ cvs -d $CVSROOT checkout wine "2005-09-21 05:20 CDT" which ends up returning: cvs checkout: cannot find module `2005-09-21 05:20:20 CDT' - ignored I would like to be able to determine which patch specifically is responsible. Any help with CVS would be useful here. thank you Lee Parsons

2 1