July 2007 - Wine-Devel - list.winehq.org

Re: server: Only commit SetThreadPriority if new priority is correct (try 2)
by Robert Shearman July 19, 2007

July 19, 2007

Matt Jones wrote: > + if ((req->priority >= min || > + req->priority == THREAD_PRIORITY_IDLE) || > + (req->priority <= max || > + req->priority == THREAD_PRIORITY_TIME_CRITICAL)) > + thread->priority = req->priority; > + } > This doesn't look correct. There should be an && in there instead of one of the || operators. -- Rob Shearman

2 1

Re: server: Only commit SetThreadPriority if new priority is correct (try 2)
by Matt Jones July 19, 2007

July 19, 2007

Could someone please review this? Thank you, Matt On 7/17/07, Matt Jones <mattj(a)google.com> wrote: > Fixes compliance with the test I just sent in. > > Try 2 adds constants for realtime min/max priorities & deletes > todo_wine from the fixed tests > >

1 0

Re: kernel32: Additional SetThreadPriorityTest
by Matt Jones July 19, 2007

July 19, 2007

Could someone please review this? Thank you, Matt On 7/17/07, Matt Jones <mattj(a)google.com> wrote: > SetThreadPriority should maintain the current thread priority if an > invalid thread priority number is passed in. > > Now uses todo_wine flag > >

1 0

Re: [1/6] WineD3D: Create the stateblock in Init3D
by Alexandre Julliard July 19, 2007

July 19, 2007

Stefan Dösinger <stefan(a)codeweavers.com> writes: > These patches get ddraw without opengl working again. In the last versions > this has failed because wined3d tries to find the gl caps when the first > wined3d object is created and refuses to work if this fails. This patchset > makes ddraw working again on a VNC X server. ../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so device.c && touch device.ok wine: Unhandled page fault on execute access to 0x00000000 at address (nil) (thread 000b), starting debugger... WineDbg starting on pid 000a Unhandled exception: page fault on execute access to 0x00000000 in 32-bit code (0x00000000). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00000000 ESP:0033fa8c EBP:0033fac8 EFLAGS:00010246( - 00 -RIZP1) EAX:001a1ac0 EBX:61a5c8f8 ECX:00161460 EDX:001cbae8 ESI:00000001 EDI:61a5d398 Stack dump: 0x0033fa8c: 619cf859 001a1ac0 00000000 001df6d8 0x0033fa9c: 616f59a8 00001302 0021d498 00000000 0x0033faac: 602cbc71 001a1998 61a43621 0000002b 0x0033fabc: 61706640 00000000 001611e8 0033faf8 0x0033facc: 616f5a4e 00161460 616f7e30 616f7f80 0x0033fadc: 606164bc 606171ff 0000005c 00000000 Backtrace: =>1 0x00000000 (0x0033fac8) 2 0x616f5a4e IDirect3DDevice8Impl_Release+0xbe(iface=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/d3d8/device.c:111] in d3d8 (0x0033faf8) 3 0x6060b3b1 test_swapchain+0xa31() [/home/julliard/wine/wine/dlls/d3d8/tests/device.c:267] in d3d8_test (0x0033fbc8) 4 0x6060d518 func_device+0x3a8() [/home/julliard/wine/wine/dlls/d3d8/tests/device.c:310] in d3d8_test (0x0033fe58) 5 0x60616238 run_test+0x128(name=0x110395) [/home/julliard/wine/wine/dlls/d3d8/tests/../../../include/wine/test.h:389] in d3d8_test (0x0033fea8) 6 0x606168cd main+0x14d(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/d3d8/tests/../../../include/wine/test.h:437] in d3d8_test (0x0033fed8) 7 0x60616fab __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in d3d8_test (0x0033ff08) 8 0x604087de start_process+0xee(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:820] in kernel32 (0x0033ffe8) 9 0x60027af7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x00000000: addb %al,0x0(%eax) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: tooltips: avoid buffer overrun (spotted by hto@mail.cnt.ru, bug #8361), make sure some strings are NUL-terminated
by Alexandre Julliard July 19, 2007

July 19, 2007

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > @@ -389,10 +390,10 @@ static void TOOLTIPS_GetDispInfoW(HWND hwnd, TOOLTIPS_INFO *infoPtr, TTTOOL_INFO > sizeof(ttnmdi.szText)/sizeof(ttnmdi.szText[0]) : INFOTIPSIZE-1; > lstrcpynW(infoPtr->szTipText, ttnmdi.lpszText, max_len); > if (ttnmdi.uFlags & TTF_DI_SETITEM) { > - INT len = max(strlenW(ttnmdi.lpszText), max_len); > + INT len = min(strlenW(ttnmdi.lpszText), max_len); It the text is really allowed to not be null-terminated then calling strlenW on it is wrong in any case. It does seem surprising though, are you sure we really need to support this? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [1/10] gdiplus: added GdipScaleMatrix [try2]
by Alexandre Julliard July 19, 2007

July 19, 2007

"Evan Stade" <estade(a)gmail.com> writes: > +GpStatus WINGDIPAPI GdipScaleMatrix(GpMatrix *matrix, REAL scaleX, REAL scaleY, > + GpMatrixOrder order) > +{ > + REAL scale[6]; > + > + if(!matrix) > + return InvalidParameter; > + > + memset(scale, 0, 6 * sizeof(REAL)); Using memset for floats is not a good idea, you should use explicit initialization. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [4/6] WineD3D: Attempt to clean up fbos only if a gl surface is destroyed
by H. Verbeet July 19, 2007

July 19, 2007

On 18/07/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > This code does not really have a home. For one part the device is in > charge of managing the gl fbos, on the other hand this is gl surface > specific code and should go into IWineD3DSurface::Release. No, the surface release code shouldn't know about render targets, FBOs, etc. (It's not really surface specific either, other than that the pointers we're cleaning up happen to be surfaces.) The device gets notified when resources of a certain type are destroyed here, so it can do extra cleanup on it's internal structures, so this is the correct place to do this kind of stuff.

2 3

peek_message reading bogus data from wineserver
by Phil Lodwick July 18, 2007

July 18, 2007

Greetings! I have been chasing down a bug and was hoping to get a few suggestions as to what to look at next. In an application's main message loop it calls GetMessage. Occasionally this call would hit an assert within Wine code. Tracking this down I have found a problem in the call to the wineserver in the peek_message routine in user/message.c. This routine will make a "get_message" wine server request, successfully read 64 bytes of data, but the data in the buffer is bogus. I can put debug in server/request.c/send_reply and see that the data being written by the server is correct. Similar debug in dlls/ntdll/server.c/read_reply_data shows that the data being read is wrong. I am pretty sure this is a timing related problem. Has anybody seen something similar or have any suggestions on what more to look at? Thanks, Phil

1 0

PulseAudio driver
by Stéphan Kochen July 18, 2007

July 18, 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I've been working on a PulseAudio driver for Wine for a couple of days now. It was suggested I should drop a note on to wine-devel, so here I am. :) I also cc'd pulseaudio-discuss. (And subscribed to both.) I personally use PulseAudio for everything on my desktop already, but support in Wine was lacking. PulseAudio provides lots of compatibility with other APIs, like OSS, ALSA and ESD. I only managed to get OSS emulation working to a reasonable extent with Wine. I decided it would be a fun project to write a native PulseAudio driver instead. Right now I'm trying to get very basic output working, without real support for DirectSound. Using the winmm_test.exe.so testcase from Wine I already managed to produce beeps using my driver, which is pretty cool for just a couple of days work. :) If anyone feels like a chat, I read both these lists now and will try to respond. I can also be found on Freenode in #winehackers and #pulseaudio as 'stephank'. - -- Stéphan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGEOThcFUq0gzqDwQRAr5mAKCn2PenC5f8iUKEywPe2c8J6s3bogCdH6qv 3JCaQX5OIBwMV9znBXYKJh4= =gQT3 -----END PGP SIGNATURE-----

2 1

Stencil fbo attachments
by Stefan Dösinger July 18, 2007

July 18, 2007

Hi Henri, Apparently I have debugged Splinter Cell in a wrong direction. The depth copy can hardly be the problem because splinter cell renders everything offscreen, except the final composition and the HUD. I think the problem is the lack of a stencil attachment to our fbos. Implementing them looks rather simple - just adjust the internal format of D24S8 to the packed depth stencil format and set the same texture for depth and stencil attachments. However, I think I remember that you tried that before and it failed for some reason. There are two extensions, GL_NV_packed_depth_stencil and GL_EXT_packed_depth_stencil, whereas the NV one is the only one supported on my nvidia card and the EXT one the only one supported on my ATI card(on macos). The EXT one seems to be the only one that is written with fbos in mind. fglrx does not support either extension. As a fallback a combined depth stencil surface could contain an extra 8 bit gl texture(luminance, or GL_RED, or whatever) and just use it as a separate stencil buffer. We just have to watch out when locking the texture, and using such a surface for texuring will be tricky. (Stencil texture? Is that possible even? The EXT_packed_stencil extension says yes).

3 11