July 2008 - Wine-devel - list.winehq.org

Re: ole32: fix a bad return value for DefaultHandler_SetExtent
by Rob Shearman 27 Jul '08

27 Jul '08

2008/7/26 <f.dorin(a)free.fr>: > fix a bad return value for DefaultHandler_SetExtent implemented in defaulthandler.c > > ChangeLog entry: > * real name : François DORIN > * email : f.dorin(a)free.fr > * description : when the server is running, the return value must be the value of the delegating method and not OLE_E_NOTRUNNING. Good spot. Your patch looks good to me. -- Rob Shearman

1 0

Re: ole32: fix offsets managment
by Rob Shearman 27 Jul '08

27 Jul '08

2008/7/26 <f.dorin(a)free.fr>: > It's my first patch. So, if something is wrong, don't hesitate to notify me ! > > ChangeLog entry : > * real name : François DORIN > * email : f.dorin(a)free.fr > * description : offsets can be negative. It is necessary to treat them as signed numbers to avoid unexpected behaviors. Thank you for your first contribution, but first of all the subject isn't correct as the patch is to rpcrt4 instead of ole32. Second of all, the patch is not correct as it is widl that is generating the wrong format string here: http://www.winehq.org/pipermail/wine-patches/2008-June/056332.html http://www.winehq.org/pipermail/wine-devel/2008-June/066587.html -- Rob Shearman

1 0

re: ole32: fix offsets managment
by Dan Kegel 27 Jul '08

27 Jul '08

f.dorin at free.fr wrote: > It's my first patch. So, if something is wrong, don't hesitate to notify me ! > ... > + if (*(const WORD*)pFormat) pointer_desc = pFormat + *(const SHORT*)pFormat; Hi François! A few quick notes: 1) it's helpful if you can say what app each patch fixes, and what the symptom was 2) it's very helpful if you can include a conformance test with each patch. It can probably be just a few lines added to an existing conformance test. 3) In this patch, it looks kind of funny to use WORD and SHORT for same type, may as well change the type in the conditional, too. - Dan

1 0

Re: GL_INVALID_ENUM errors with FBO
by Vitaliy Margolen 27 Jul '08

27 Jul '08

H. Verbeet wrote: > 2008/7/24 Vitaliy Margolen <wine-devel(a)kievinfo.com>: >>>> side affects. But the full version of Psychonauts crashes after initial >>>> videos. Same as it did when we had problems with multi-threaded games. >>>> >>> Is that a regression introduced by the patch? >> Yes. Without the patch everything works. With the patch it crashes. > It's a bit unfortunate that it only happens in the full version. Have > you got any idea which part of that patch is causing the crash? Is it > the Clear call again? In the original case it was pretty clear that > calling apply_fbo_state() without activating the context for the > current thread caused issues, but as far as I can see that part should > still work correctly with my patch. It's this part: diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c index 9a47f8b..f2ab699 100644 --- a/dlls/wined3d/drawprim.c +++ b/dlls/wined3d/drawprim.c @@ -974,6 +974,7 @@ void drawPrimitive(IWineD3DDevice *iface, /* Signals other modules that a drawing is in progress and the stateblock finalized */ This->isInDraw = TRUE; + ActivateContext(This, This->render_targets[0], CTXUSAGE_DRAWPRIM); /* Ok, we will be updating the screen from here onwards so grab the lock */ @@ -983,7 +984,6 @@ void drawPrimitive(IWineD3DDevice *iface, LEAVE_GL(); } - ActivateContext(This, This->render_targets[0], CTXUSAGE_DRAWPRIM); ENTER_GL(); if (This->stencilBufferTarget) {

3 10

Path reset on wine update
by Massimo Del Fedele 26 Jul '08

26 Jul '08

Maybe that's an already asked question, but.... why does wine reset path on each wine update ? That's becoming annoying... I mus reedit registry on each update to make my apps work again. Ciao Max

3 5

iTunes ipod support
by Mathias Karwath 26 Jul '08

26 Jul '08

Hi, im from Germany and i would use iTunes with the iPod Touch. I saw a Post on the Mailing list that its possible to Sync the Touch over iTunes using wine, but its not implemented yet. Is it possible to get the Patches? Im suck of using iTunes in a VM with Windows on my System. So i would like to test the Patches. Please! :) regards Mathias Karwath

3 2

Signature checking in Wine
by Juan Lang 26 Jul '08

26 Jul '08

Folks, now that there's a bit more code in Wine that "verifies" file signatures, I wanted to make sure everyone understands its current limitations. 1. It's only implemented for PE files and .cab files. Windows supports more formats, of course, notably MSI files (see bug 11759, http://bugs.winehq.org/show_bug.cgi?id=11759 ) 2. Wine doesn't actually verify that the signature in the file matches the file being checked. Any valid certificate could be put into a file, and Wine would accept it. I don't consider this a serious security flaw, because I think the concept of a signature validating anything useful about a binary is flawed. Hence I'm not terribly motivated to fix it. Flame away, --Juan

4 5

Midterm evaluations for summer of code students
by Maarten Lankhorst 25 Jul '08

25 Jul '08

Hi students, As you might know it's time for midterm evaluations. Unfortunately for some students I haven't seen the progress they made, and I highly encourage all students to send their patches early and often, even if it's not yet finished. Also, I would like to hear from all students now a reflection. What went well, and what didn't, and what did you accomplish so far? :-) Cheers, Maarten.

7 6

Re: [try 4] gdi32/tests: Add tests for GdiGetCodePage.
by Alexandre Julliard 25 Jul '08

25 Jul '08

"Huang, Zhangrong" <hzhrong(a)gmail.com> writes: > This patch add tests for GdiGetCodePage, all failed stuff has been > marked as todo_wine. It doesn't work here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:850: Test succeeded inside todo block: data index 2: expected font codepage 1252, got 1252 font.c:853: Test succeeded inside todo block: data index 2: GdiGetCodePage should have returned 1252, got 1252 font.c:850: Test succeeded inside todo block: data index 3: expected font codepage 1252, got 1252 font.c:853: Test succeeded inside todo block: data index 3: GdiGetCodePage should have returned 1252, got 1252 font.c:850: Test succeeded inside todo block: data index 15: expected font codepage 1253, got 1253 font.c:853: Test succeeded inside todo block: data index 15: GdiGetCodePage should have returned 1253, got 1253 font.c:850: Test succeeded inside todo block: data index 16: expected font codepage 1251, got 1251 font.c:853: Test succeeded inside todo block: data index 16: GdiGetCodePage should have returned 1251, got 1251 font.c:1579: Tests skipped: Symbol or Wingdings is not installed font.c:1595: Tests skipped: Symbol or Wingdings is not installed font.c:1749: Tests skipped: Symbol is not installed font.c:2557: Tests skipped: Arial Black or Symbol/Wingdings is not installed font.c:1975: Tests skipped: Font DejaVu Sans doesn't contain 'x', skipping the test font.c:1975: Tests skipped: Font DejaVu Sans Condensed doesn't contain 'x', skipping the test font.c:1975: Tests skipped: Font OpenSymbol doesn't contain 'x', skipping the test make[2]: *** [font.ok] Error 8 -- Alexandre Julliard julliard(a)winehq.org

3 2

DSurface optimization, comments requested
by Aric Stewart 25 Jul '08

25 Jul '08

Hi there, I was playing with a older Japanese side scrolling shooter benchmark and was getting 4.3 frames per second. Some digging revealed that the game made extensive use of Blt on gdi surfaces and it looks like the current implementation of Blt actually locks the entire destination surface to blt to it. This then causes the Unlock to copy the entire screen out. This means that every time any sprite moved the entire screen redrew. I threw together this patch, which seems far to simple to be at all correct, and suddenly i was getting 28.8 frames per second. I know it is not fully correct because a a portion of the game (drawn by FastBlt it looks like) stopped rendering correctly with this patch. But I thought it may get someone who knows that area better thinking about it. If we can optimize this then a number of the scrolling shooter games will become playable. I am told that these style games are still very popular here. And if said people in the know where to busy, maybe they could give me some pointers on if I have the right approach or not. If anyone is interested I can provide an archive with the benchmark program in it. -aric diff --git a/dlls/wined3d/surface_base.c b/dlls/wined3d/surface_base.c index 57809e1..2ec3a52 100644 --- a/dlls/wined3d/surface_base.c +++ b/dlls/wined3d/surface_base.c @@ -852,7 +852,7 @@ IWineD3DBaseSurfaceImpl_Blt(IWineD3DSurface *iface, if (Src == This) { - IWineD3DSurface_LockRect(iface, &dlock, NULL, 0); + IWineD3DSurface_LockRect(iface, &dlock, DestRect, 0); dfmt = This->resource.format; slock = dlock; sfmt = dfmt; @@ -877,20 +877,26 @@ IWineD3DBaseSurfaceImpl_Blt(IWineD3DSurface *iface, sfmt = Src->resource.format; } sEntry = getFormatDescEntry(sfmt, NULL, NULL); - IWineD3DSurface_LockRect(iface, &dlock,NULL,0); + IWineD3DSurface_LockRect(iface, &dlock, DestRect,0); } if (!DDBltFx || !(DDBltFx->dwDDFX)) Flags &= ~WINEDDBLT_DDFX; if (sEntry->isFourcc && dEntry->isFourcc) - { - memcpy(dlock.pBits, slock.pBits, This->resource.size); - goto release; + { + if (!DestRect) + { + memcpy(dlock.pBits, slock.pBits, This->resource.size); + goto release; + } } if (DestRect) { - xdst = *DestRect; + xdst.top = 0; + xdst.bottom = DestRect->bottom - DestRect->top; + xdst.left = 0; + xdst.right = DestRect->right - DestRect->left; } else {

3 2