September 2007 - Wine-Devel

Re: First song purchased on iTunes 7 with Wine...

by Jeremy White

Dan Kegel wrote: > For the record, I just bought "Autobahn" by Kraftwerk > for $0.99 from the iTunes store using iTunes 7 on > today's wine from git. It's playing now while I type > this message. (OK, the music skips sometimes when I type > or adjust the volume or move the mouse or scratch my nose... > but hey, at least it's a start!) 7.4.2? I tried that last night, and didn't end up getting any files installed. Am I missing any tricks? I had a virgin .wine... Cheers, Jeremy

Sept. 13, 2007

Re: First song purchased on iTunes 7 with Wine...

by Juan Lang

> For the record, I just bought "Autobahn" by Kraftwerk > for $0.99 from the iTunes store using iTunes 7 on > today's wine from git. It's playing now while I type > this message. (OK, the music skips sometimes when I type > or adjust the volume or move the mouse or scratch my nose... > but hey, at least it's a start!) Sick ;) I just tried by iPod - no love there. Looks like setupapi's going to need some work.. --Juan

Sept. 13, 2007

First song purchased on iTunes 7 with Wine...

by Dan Kegel

For the record, I just bought "Autobahn" by Kraftwerk for $0.99 from the iTunes store using iTunes 7 on today's wine from git. It's playing now while I type this message. (OK, the music skips sometimes when I type or adjust the volume or move the mouse or scratch my nose... but hey, at least it's a start!) Thanks, Juan! - Dan

Sept. 13, 2007

Re: [2/2] WGL: Sync pixmap after glFlush/glFinish, not before every GL call

by Alexandre Julliard

Chris Robinson <chris.kcat(a)gmail.com> writes: > Is the pixmap updated with the DIB memory, or is the DIB memory updated with > the pixmap? In the latter case, it should be fine. It's supposed to work both ways. > Also, I'm not even sure a DIB can have a proper GL context, given that GL > rendering by nature is device-dependant (possibly forgoing generic/software > rendering, which we don't export). Is there anything which shows this is > possible, or should I try to make some tests? Tests would definitely be a good idea. -- Alexandre Julliard julliard(a)winehq.org

Sept. 13, 2007

Re: [2/2] WGL: Sync pixmap after glFlush/glFinish, not before every GL call

by Chris Robinson

On Thursday 13 September 2007 04:40:03 am Alexandre Julliard wrote: > Chris Robinson <chris.kcat(a)gmail.com> writes: > > From 95214f29672566796564db30ab7f61a2462e4e50 Mon Sep 17 00:00:00 2001 > > From: Chris Robinson <chris.kcat(a)gmail.com> > > Date: Wed, 12 Sep 2007 06:42:05 -0700 > > Subject: [PATCH] WGL: Sync pixmap after glFlush/glFinish, not before > > every GL call > > The goal is to sync the pixmap before we start drawing to it, so doing > it at glFlush time is too late. Is the pixmap updated with the DIB memory, or is the DIB memory updated with the pixmap? In the latter case, it should be fine. Also, I'm not even sure a DIB can have a proper GL context, given that GL rendering by nature is device-dependant (possibly forgoing generic/software rendering, which we don't export). Is there anything which shows this is possible, or should I try to make some tests?

Sept. 13, 2007

Re: avifil32: Fix some memory leaks

by Kuba Ober

On Wednesday 12 September 2007, Paul Vriens wrote: > Andrew Talbot wrote: > > Changelog: > > avifil32: Fix some memory leaks. > > > > > > - if (mmioSeek(This->paf->hmmio, This->paf->dwNextFramePos, SEEK_SET) > > == -1) - return AVIERR_FILEWRITE; > > - if (mmioCreateChunk(This->paf->hmmio, &ck, 0) != S_OK) > > - return AVIERR_FILEWRITE; > > - if (mmioWrite(This->paf->hmmio, (HPSTR)lppc, ck.cksize) != > > ck.cksize) - return AVIERR_FILEWRITE; > > - if (mmioAscend(This->paf->hmmio, &ck, 0) != S_OK) > > + if (mmioSeek(This->paf->hmmio, This->paf->dwNextFramePos, SEEK_SET) > > == -1 || + mmioCreateChunk(This->paf->hmmio, &ck, 0) != S_OK || > > + mmioWrite(This->paf->hmmio, (HPSTR)lppc, ck.cksize) != ck.cksize > > || + mmioAscend(This->paf->hmmio, &ck, 0) != S_OK) > > + { > > Doesn't this mean that every one of those 4 mmio-calls are executed? In the > previous logic we would bail out after one failure. No. They are evaluated left-to-right, and evaluation stops on the first one returning true. Cheers, Kuba

Sept. 13, 2007

Re: wineprefixcreate: Make sure the path returned by GetTempPath() during the $WINEPREFIX creation will be writable.

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > mshtml.dll (and probably many others) use GetTempPath() during the > self-registration process. But at that point the Windows environment > variables, and in particular $TMP and $TEMP, have not been set yet, > especially not in the currently running process. So when mshtml.dll > calls GetTempPath(), that function returns the current directory, which > obviously is no good if that directory is not writable (like '/' for > instance). So this patch makes 'c:\windows\temp' the current directory, > which we know will be writable (and the chdir() should have no other > side effect in this script). Actually GetTempPath is not supposed to use the current directory, I committed a fix. -- Alexandre Julliard julliard(a)winehq.org

Sept. 13, 2007

Re: [2/2] WGL: Sync pixmap after glFlush/glFinish, not before every GL call

by Alexandre Julliard

Chris Robinson <chris.kcat(a)gmail.com> writes: > From 95214f29672566796564db30ab7f61a2462e4e50 Mon Sep 17 00:00:00 2001 > From: Chris Robinson <chris.kcat(a)gmail.com> > Date: Wed, 12 Sep 2007 06:42:05 -0700 > Subject: [PATCH] WGL: Sync pixmap after glFlush/glFinish, not before every GL call The goal is to sync the pixmap before we start drawing to it, so doing it at glFlush time is too late. -- Alexandre Julliard julliard(a)winehq.org

Sept. 13, 2007

Re: gdi32[2/4]: implement AddFontMemResourceEx (based on a patch of Byeong-Sik Jeon, helps with bug #5865) (resend)

by Alexandre Julliard

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c > index c516736..efc044b 100644 > --- a/dlls/gdi32/font.c > +++ b/dlls/gdi32/font.c > @@ -3214,8 +3214,18 @@ BOOL WINAPI RemoveFontResourceW( LPCWSTR > */ > HANDLE WINAPI AddFontMemResourceEx( PVOID pbFont, DWORD cbFont, PVOID pdv, DWORD *pcFonts) > { > - FIXME("(%p,%08x,%p,%p): stub\n", pbFont, cbFont, pdv, pcFonts); > - return NULL; > + PVOID pFontCopy = HeapAlloc(GetProcessHeap(), 0, cbFont); > + HANDLE ret; > + > + TRACE("Copying %d bytes of data from %p to %p\n", cbFont, pbFont, pFontCopy); > + memcpy(pFontCopy, pbFont, cbFont); > + ret = WineEngAddFontMemResourceEx(pFontCopy, cbFont, pdv, pcFonts); > + if (ret == NULL) > + { > + TRACE("Font create failed - freeing %p\n", pFontCopy); > + HeapFree(GetProcessHeap(), 0, pFontCopy); > + } > + return ret; > } The memory copy should be done in WineEngAddFontMemResourceEx since that's where the data is managed. -- Alexandre Julliard julliard(a)winehq.org

Sept. 13, 2007

Re: winex11.drv/wintab32[1/5]: store categories field-by-field (resend)

by Alexandre Julliard

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > /*********************************************************************** > * X11DRV_WTInfoA (X11DRV.@) > + * > + * NOTES > + * If cchOnlyCountString is not NULL and the data is a string then no > + * data is stored in the output buffer but only the string length is > + * returned in *cchOnlyCountString (and is >= 1 as contains at least a NUL > + * character). It have no effect on non-string data. > + * > + * Apart from the cchOnlyCountString parameter this function differs from the > + * WTInfo[AW] as for nIndex == 0 it returns the number of items in the > + * category. It's wintab32.dll that concatenates the data > + * > + * It is valid to call WTInfoA with lpOutput == NULL, as per standard. > + * lpOutput == NULL signifies the user only wishes to find the size of > + * the data. > */ > -UINT X11DRV_WTInfoA(UINT wCategory, UINT nIndex, LPVOID lpOutput) > +UINT X11DRV_WTInfoA(UINT wCategory, UINT nIndex, LPVOID lpOutput, DWORD *cchOnlyCountString) You shouldn't change the prototype. Driver functions should follow the signature of the corresponding APIs as far as possible. -- Alexandre Julliard julliard(a)winehq.org

Sept. 13, 2007

Re: [5/5] WineD3D: Pixel shader 1.x constants are clamped to [-1;1]

by Stefan Dösinger

Am Donnerstag, 13. September 2007 12:43:54 schrieb Alexandre Julliard: > Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > This one fails make test for me: > quad 4 has color 00bfbf7f, expected 0x00bfbf80 make[2]: *** [visual.ok] This looks like a precision problem (7f vs 80). I will make the test less picky.

Sept. 13, 2007

Re: [5/5] WineD3D: Pixel shader 1.x constants are clamped to [-1;1]

by Alexandre Julliard

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: > It is hard to judge if this patch will fix anything. A problem is that > clamping the constants on loading makes constants loading more expensive. > Luckilly though there aren't many ps 1.x constants(8 max). It is hard to say > if there are any games that use constants > 1.0, but incorrect constant > loading can have many bad effects. This one fails make test for me: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:3068: Test failed: quad 1 has color 00bfbf7f, expected 0x00bfbf80 visual.c:3070: Test failed: quad 2 has color 00bfbf7f, expected 0x00bfbf80 visual.c:3073: Test failed: quad 3 has color 00bfbf7f, expected 0x00bfbf80 visual.c:3077: Test failed: quad 4 has color 00bfbf7f, expected 0x00bfbf80 visual.c:3207: Test failed: quad 1 has color 007f7f00, expected 0x00808000 visual.c:3209: Test failed: quad 2 has color 007f7f00, expected 0x00808000 visual.c:3211: Test failed: quad 3 has color 007f7f00, expected 0x00808000 visual.c:3214: Test failed: quad 4 has color 00bfbf7f, expected 0x00bfbf80 make[2]: *** [visual.ok] Error 8 -- Alexandre Julliard julliard(a)winehq.org

Sept. 13, 2007

carbon poker under wine

by Trent Waddington

On 9/13/07, Eric Andersen <xxxx(a)xxx.com> wrote: > I was wondering if you could possibly throw me some pointers for > getting Carbon Poker working under wine. > > For the record I'm using ubuntu feisty and wine 0.9.44. I'll forward this to wine-devel, as someone else might want it. Well, first thing you should try is building wine from the git tree. This is painful and annoying because Linus is stupid and ugly but there's been a lot of fixes to the crypt32 stuff recently, and you'll need that: git clone git://source.winehq.org/git/wine.git wine cd wine ; ./configure ; make etc. You can try what I'm doing with your current version first, as it has some of this crypt32 stuff.. so it might work. I downloaded CarbonPoker.exe from the website, ran it with wine and it complains that I don't have flash8 and then just sits there and does nothing. I don't know what it is doing, so I just went downloaded Flash: wget http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_play… ./wine install_flash_player.exe That installs happily. So, running CarbonPoker.exe again.. ./wine CarbonPoker.exe err:ole:COMPOBJ_DllList_Add couldn't load in-process dll L"C:\\windows\\system32\\Macromed\\Flash\\Flash9b.ocx" Uhhh, ok. Having a look in that dir I see a Flash9.ocx but no Flash9b.ocx, what the hell? cd ~/.wine/drive_c/windows/system32/Macromed/Flash/ ln -s Flash9.ocx Flash9b.ocx cd - ./wine CarbonPoker.exe and now it is happy and starts "Installing software..." which actually means it is updating the stub.. which it then runs, and starts "Installing software..." again.. You can ignore the "HTML rendering is currently disabled" where the installer would usually be telling you about the great benefits you get from playing Carbon Poker. Eventually this finishes. The installer goes away.. and after waiting and waiting, I get bored and hit CTRL-C. Fine, let's just run it then: ./wine ~/.wine/drive_c/Program\ Files/CarbonPoker/Poker.exe I get a "It appears the software has generated a bug. You can optionally submit it with comments about what you were doing at..." and as much as I'd like to do that with something like "doesn't work under wine" I'm going to press Cancel. Now we're in the login screen and it's asking me how I'd like to login, etc. So it looks like it is running! Just to check, I'm closing it and running it again.. yep, I'm in the login screen again. It's running. Hmm, I have a login for this game around here somewhere.. putting in my email address and pressing "Forgot Password" gives me this error: wine: Call from 0x7ee53f40 to unimplemented function urlmon.dll.HlinkSimpleNavigateToMoniker, aborting That isn't much help. And that crashed it, so running it again.. Sidenote: http://www.carbonpoker.com/pass.html is not secure.. ever heard of "denial of service" guys? Anyway, got some login details. Logged in, I see spam. Click on "Poker Tables". Up some come. Click on the first non-full one and "Join Table". And yes, I can join the table and sit down. I'm playing Poker. Yah. Trent

Sept. 13, 2007

Re: WGL: Fix a major ATI regression

by Joerg Mayer

On Thu, Sep 13, 2007 at 01:09:14AM +0200, Roderick Colenbrander wrote: > The change isn't a hack but more a workaround. I have submitted the bugreport to ATI but they likely won't fix it anytime soon. Well, if I understood the ATI development cycle correctly, even if they fixed it right away it will take another two releases (months) until it is released. ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

Sept. 13, 2007

Cvs update error.

by Anatoly Lyutin

Hi all!! Today I tried to make cvs update and cvs extradites a error: [vostok(a)windsor wine]$ cvs update cvs [update aborted]: unrecognized auth response from cvs.winehq.org: cvs pserver: /home/wine/CVSROOT/config [8]: warning: this CVS does not support PreservePermissions What happens? -- Best regards Anatoly Lyutin.

Sept. 13, 2007

Re: WineHQ Downtime

by Scott Ritchie

Jeremy Newman wrote: > This is a reminder. WineHQ will be going offline for upgrades today at > 14:00 CDT (19:00 GMT). > > I expect downtime to be no longer than one hour. Some services will > appear to have sporadic outages even after the upgrade is complete. This > will be due to changes in configs and upgraded versions of server > software. > > I will post back to wine-devel when the upgrade is complete. > So, when are we upgrading the wiki software to no be so hideously ugly? Thanks, Scott Ritchie

Sept. 12, 2007

Re: WGL: Fix a major ATI regression

by Chris Robinson

On Wednesday 12 September 2007 04:09:14 pm Roderick Colenbrander wrote: > + visinfo = pglXGetVisualFromFBConfig(display, cfgs[i]); > + /* We have found an offscreen rendering format when there is no > visualinfo :) */ > + if(visinfo->visualid == visualid) { > pglXGetFBConfigAttrib(display, cfgs[i], GLX_FBCONFIG_ID, > &fmt_id); > fbconfig = cfgs[i]; > } You're using visinfo before making sure it's valid. And I think that comment is a little misleading talking about offscreen formats when checking for the default visual. > + if(!visinfo) { > nOffscreenFormats++; > } > + XFree(visinfo); I don't think we can rely on being able to safely XFree a NULL pointer. None of the other code in opengl.c relies in that behavior.

Sept. 12, 2007

Re: WineHQ Downtime

by Chris Morgan

Excellent news. Thanks Jeremy. Chris On 9/12/07, Jeremy Newman <jnewman(a)codeweavers.com> wrote: > OK, the server is back online. There still may be small outages for the > next few days as I tweak config files and such. > > For the web developers (appdb guys), WineHQ.org is now using: > > PHP 5.2 > mySQL 5.0 > > You can now start committing patches using the new PHP5 capabilities. > > Enjoy! > > On Wed, 2007-09-12 at 09:56 -0500, Jeremy Newman wrote: > > This is a reminder. WineHQ will be going offline for upgrades today at > > 14:00 CDT (19:00 GMT). > > > > I expect downtime to be no longer than one hour. Some services will > > appear to have sporadic outages even after the upgrade is complete. This > > will be due to changes in configs and upgraded versions of server > > software. > > > > I will post back to wine-devel when the upgrade is complete. > > > > > > > > > > > >

Sept. 12, 2007

Re: [3/5] WineD3D: Fix the reflection calculation in texm3x3(v)spec

by H. Verbeet

On 12/09/2007, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > ...so what the patch *actually* does in a completely obfuscated way, is getting rid of the assumption that the normal is normalized. IOW, - shader_addline(buffer, "tmp0.xyz = reflect(-tmp1.xyz, tmp0.xyz);\n"); + shader_addline(buffer, "tmp0.xyz = reflect(-tmp1.xyz, normalize(tmp0.xyz));\n"); would be just as effective. That also means that the change in the ARB implementation - /* Calculate reflection vector (Assume normal is normalized): RF = 2*(N.E)*N -E */ + /* Calculate reflection vector (Assume normal is normalized): + * See comment in the glsl implementation. is misleading at best.

Sept. 12, 2007

Re: WineHQ Downtime

by Jeremy Newman

OK, the server is back online. There still may be small outages for the next few days as I tweak config files and such. For the web developers (appdb guys), WineHQ.org is now using: PHP 5.2 mySQL 5.0 You can now start committing patches using the new PHP5 capabilities. Enjoy! On Wed, 2007-09-12 at 09:56 -0500, Jeremy Newman wrote: > This is a reminder. WineHQ will be going offline for upgrades today at > 14:00 CDT (19:00 GMT). > > I expect downtime to be no longer than one hour. Some services will > appear to have sporadic outages even after the upgrade is complete. This > will be due to changes in configs and upgraded versions of server > software. > > I will post back to wine-devel when the upgrade is complete. > > > >

Sept. 12, 2007

Re: problem with silly CreateBitmap call

by Reece Dunn

On 12/09/2007, Rolf Kalbermatter <r.kalbermatter(a)hccnet.nl> wrote: > denis.bonnenfant(a)diderot.org wrote: > > >I experienced exactly the same problem with Solidworks 2007 > >http://appdb.winehq.org/appview.php?iVersionId=8983 > >with occasionnal big slowdowns caused by a 10000x10000x24bpp bitmap > >allocation. > >In this case it doesn't crashed, but allocate more than 1GB of swap. > > > >I filed a bug : > > > >http://bugs.winehq.org/show_bug.cgi?id=9561 > > Well in the log at around line 3000 and 3072 I see the problem. > A 10000 * 10000 24 bit bitmap seems quite a little excessive to me > and it creates two of them. And it creates a third bitmap with a > different y dimension but the rest is the same. > Could be really an unitialized variable somehow. Now to find out > who calls CreateCompatibleBitmap at that position! Could be the > app itself so the question would be where did it get those parameters > from. Other debug channels inside Wine could be +bitblt, +cursor, > +icon, or one of the comdlg controls such as +imagelist. > > Several calls to > > trace:x11drv:X11DRV_SetWindowPos win 0x30274 window (0,0)-(10000,14) > client (0,0)-(10000,14) style 5001000b > > right after that look also suspicious. Hmm... because the size of the window on the X axis, I would suspect the bug lies in one of the API that is used by flicker-free drawing logic when rendering to a DC. The idiom is something like: void FlickerFree(HWND window, HDC dc) { RECT client; HDC memoryDC; HBITMAP memoryBuffer, oldBitmap; GetClientRect(window, &client); /* Create a DC that has the same properties as the one we are drawing to... */ memoryDC = CreateCompatibleDC(dc); /* Create a bitmap to contain the image data of what is being drawn... */ memoryBuffer = CreateCompatibleBitmap(dc, client.right-client.left, client.bottom-client.top); oldBitmap = SelectObject(memoryDC, memoryBuffer); /* Do the drawing operations that may cause a flicker. */ /* Update the actual DC with the content of what we have just drawn... */ BitBlt(dc, client.left, client.top, client.right-client.left, client.bottom-client.top, memoryDC, client.left, client.top, SRCCOPY); SelectObject(memoryDC, oldBitmap); DeleteObject(memoryBuffer); DeleteDC(memoryDC); } > trace:x11drv:X11DRV_CreateBitmap (0xed4) 2147483646x2147483646 > 1 bpp If the problem is indeed flicker free logic as above, this looks as though it may be CW_DEFAULT x CW_DEFAULT, where CW_DEFAULT is a constant passed to CreateWindow (see the MSDN documentation) that tells Windows to pick a default width and/or height. This leads me to suspect that a WM_PAINT message is processed before WM_SIZE or related messages, or (least likely) CW_DEFAULT is not handled properly. - Reece

Sept. 12, 2007

Re: avifil32: Fix some memory leaks

by Paul Vriens

Andrew Talbot wrote: > Paul Vriens wrote: > >> Doesn't this mean that every one of those 4 mmio-calls are executed? In >> the previous logic we would bail out after one failure. >> > > My reasoning is that short-circuit evaluation ensures that expressions are > evaluated from left to right, and as soon as one evaluates as true, the > whole "if" clause must be true, so the remaining statements are discarded. > Yes I see now, sorry about the noise (there was something wrong with my own logic). -- Cheers, Paul.

Sept. 12, 2007

Re: avifil32: Fix some memory leaks

by Andrew Talbot

Paul Vriens wrote: > Doesn't this mean that every one of those 4 mmio-calls are executed? In > the previous logic we would bail out after one failure. > My reasoning is that short-circuit evaluation ensures that expressions are evaluated from left to right, and as soon as one evaluates as true, the whole "if" clause must be true, so the remaining statements are discarded. -- Andy.

Sept. 12, 2007

Re: avifil32: Fix some memory leaks

by Paul Vriens

Andrew Talbot wrote: > Changelog: > avifil32: Fix some memory leaks. > > > - if (mmioSeek(This->paf->hmmio, This->paf->dwNextFramePos, SEEK_SET) == -1) > - return AVIERR_FILEWRITE; > - if (mmioCreateChunk(This->paf->hmmio, &ck, 0) != S_OK) > - return AVIERR_FILEWRITE; > - if (mmioWrite(This->paf->hmmio, (HPSTR)lppc, ck.cksize) != ck.cksize) > - return AVIERR_FILEWRITE; > - if (mmioAscend(This->paf->hmmio, &ck, 0) != S_OK) > + if (mmioSeek(This->paf->hmmio, This->paf->dwNextFramePos, SEEK_SET) == -1 || > + mmioCreateChunk(This->paf->hmmio, &ck, 0) != S_OK || > + mmioWrite(This->paf->hmmio, (HPSTR)lppc, ck.cksize) != ck.cksize || > + mmioAscend(This->paf->hmmio, &ck, 0) != S_OK) > + { Doesn't this mean that every one of those 4 mmio-calls are executed? In the previous logic we would bail out after one failure. -- Cheers, Paul.

Sept. 12, 2007

Re: iTunes 7

by Juan Lang

> Just a wild guess, does the attached patch fix the problem? Battlefield > 1942 shows the same behavior in windowed mode. Thanks for suggesting a fix, but that doesn't fix the problem. --Juan

Sept. 12, 2007

WineHQ Downtime

by Jeremy Newman

This is a reminder. WineHQ will be going offline for upgrades today at 14:00 CDT (19:00 GMT). I expect downtime to be no longer than one hour. Some services will appear to have sporadic outages even after the upgrade is complete. This will be due to changes in configs and upgraded versions of server software. I will post back to wine-devel when the upgrade is complete.

Sept. 12, 2007

Re: [PATCH] user32: edit control should respond to ctrl + z (try 3)

by Dmitry Timoshkov

"Lei Zhang" <thestig(a)google.com> wrote: > I feel "after every message" is bloating the test too much. If we take > the approach where we believe anything can go wrong and check > everything after every message, then we'll spend the rest of our lives > writing tests. That's certainly an exaggeration. You've already spent more time resending a not complete patch, and arguing about it. -- Dmitry.

Sept. 12, 2007

Re: WineD3D: PBO support 2/2 (attempt 2)

by Alexandre Julliard

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > This is an updated version of the patch. In the previous one I was > making a glBindBuffer call in a place without checking if PBOs were > around. Further the place didn't need the call anymore. This breaks the tests for me: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:2043: Test failed: quad 1 has color 0000ffff, expected 0x00FFFF00 visual.c:2045: Test failed: quad 2 has color 0000ffff, expected 0x0000000 visual.c:2047: Test failed: quad 3 has color 0000ffff, expected 0x0000FF00 make[2]: *** [visual.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

Sept. 12, 2007

Re: iTunes 7

by Stefan Dösinger

Am Mittwoch, 12. September 2007 04:37:51 schrieb Markus Amsler: > Juan Lang wrote: > > Folks, I just sent a series of wintrust patches that gets iTunes 7 to > > start, at least for me. I expect some will get rejected due to > > collision with Francois's patch - I'll resynch and resend. But if you > > want to play around with iTunes, grab those patches and give them a > > whirl. > > > > Known issues: > > 1. Your screen will go black when it starts. This is something > > QuickTime is doing. You can drag windows around to force some > > repainting to work around it > > Just a wild guess, does the attached patch fix the problem? Battlefield > 1942 shows the same behavior in windowed mode. The problem with QuickTime is that it does a LockRect() on the front buffer, which draws on the NULL window without a clipper set. The GetDC call you're removing here causes a simmilar issue(it also leads to a LockRect). WineD3D's gdi surfaces write to the destination window, but they do not read from it. A quick test shows that locking the primary returns the contents of the screen so we should propably read the destination window's contents if we're locking the front buffer, but AJ objected against that and I didn't put much effort in getting this patch in. However, you make a good point that wined3d inherently has that problem, due to these GetDC() and ReleaseDC(). We use them to make the surface code create a DIB section for the surface.

Sept. 12, 2007

RE: problem with silly CreateBitmap call

by Rolf Kalbermatter

denis.bonnenfant(a)diderot.org wrote: >I experienced exactly the same problem with Solidworks 2007 >http://appdb.winehq.org/appview.php?iVersionId=8983 >with occasionnal big slowdowns caused by a 10000x10000x24bpp bitmap >allocation. >In this case it doesn't crashed, but allocate more than 1GB of swap. > >I filed a bug : > >http://bugs.winehq.org/show_bug.cgi?id=9561 Well in the log at around line 3000 and 3072 I see the problem. A 10000 * 10000 24 bit bitmap seems quite a little excessive to me and it creates two of them. And it creates a third bitmap with a different y dimension but the rest is the same. Could be really an unitialized variable somehow. Now to find out who calls CreateCompatibleBitmap at that position! Could be the app itself so the question would be where did it get those parameters from. Other debug channels inside Wine could be +bitblt, +cursor, +icon, or one of the comdlg controls such as +imagelist. Several calls to trace:x11drv:X11DRV_SetWindowPos win 0x30274 window (0,0)-(10000,14) client (0,0)-(10000,14) style 5001000b right after that look also suspicious. Rolf Kalbermatter

Sept. 12, 2007

Re: [PATCH] user32: edit control should respond to ctrl + z (try 3)

by Lei Zhang

On 9/11/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Lei Zhang" <thestig(a)google.com> wrote: > > > I'll add EM_GETSEL checks as well. > > I'm sorry, but in your latest patch you have added only one EM_GETSEL, > but that's not "after every message" as repeated in each my mail. > > -- > Dmitry. > I feel "after every message" is bloating the test too much. If we take the approach where we believe anything can go wrong and check everything after every message, then we'll spend the rest of our lives writing tests. The goal of this test is to make sure undo works. I had forgotten that hitting undo after a cut restores the previous selection. So yes, the test is not thorough enough. I will check the selection and check the buffer contents at the beginning and after every undo to make sure the pre and post conditions hold. Does this seem reasonable? The goal here is not to verify setting test/cutting/pasting/selecting works. Those should be tested separately.

Sept. 12, 2007

Re: [PATCH] user32: edit control should respond to ctrl + z (try 3)

by Dmitry Timoshkov

"Lei Zhang" <thestig(a)google.com> wrote: > I'll add EM_GETSEL checks as well. I'm sorry, but in your latest patch you have added only one EM_GETSEL, but that's not "after every message" as repeated in each my mail. -- Dmitry.

Sept. 12, 2007

Re: iTunes 7

by Markus Amsler

Juan Lang wrote: > Folks, I just sent a series of wintrust patches that gets iTunes 7 to > start, at least for me. I expect some will get rejected due to > collision with Francois's patch - I'll resynch and resend. But if you > want to play around with iTunes, grab those patches and give them a > whirl. > > Known issues: > 1. Your screen will go black when it starts. This is something > QuickTime is doing. You can drag windows around to force some > repainting to work around it Just a wild guess, does the attached patch fix the problem? Battlefield 1942 shows the same behavior in windowed mode.

Sept. 11, 2007

Re: iTunes 7

by Juan Lang

> You are amazing. Thank Dan Kegel and Google for sponsoring me to work on it this summer. Luckily for me, it's ended up being almost exactly one summer's worth of work. > If iTunes 7 can be made to work by 0.9.45 (or 0.9.46), > it can make it into Ubuntu Gutsy. Seeing as how iTunes is consistently > one of our top 5 demanded apps, the improvement from the user's > perspective will be palpable. Maybe so! So, some testing would be great. There are some bugs there, like, scrolling in the Music store is very slow (that's already logged.) I have no idea of syncing with your iPod works - I keep forgetting to bring mine in to test it. So, let's see how close to working this really is, huh? --Juan

Sept. 11, 2007

Re: iTunes 7

by Scott Ritchie

Juan Lang wrote: > Folks, I just sent a series of wintrust patches that gets iTunes 7 to > start, at least for me. I expect some will get rejected due to > collision with Francois's patch - I'll resynch and resend. But if you > want to play around with iTunes, grab those patches and give them a > whirl. > > Known issues: > 1. Your screen will go black when it starts. This is something > QuickTime is doing. You can drag windows around to force some > repainting to work around it. > 2. You'll see lots of fixmes on the console, especially: > "fixme:setupapi:CMP_WaitNoPendingInstallEvents 0", > "fixme:setupapi:SetupDiGetClassDevsW returning empty list", and > "fixme:htmlhelp:HtmlHelpW HH case HH_PRETRANSLATEMESSAGE not handled." > 3. The main window will be transparent (and basically unusable) if you > don't have GL support compiled in. > > Have fun, > --Juan > > You are amazing. If iTunes 7 can be made to work by 0.9.45 (or 0.9.46), it can make it into Ubuntu Gutsy. Seeing as how iTunes is consistently one of our top 5 demanded apps, the improvement from the user's perspective will be palpable. Combined with everything else the team has been doing lately, I can just see the buzz: "Wow, Wine really is improving quickly and starting to "just work." Thanks, Scott Ritchie

Sept. 11, 2007

Re: [bugzilla] replace generic severity descriptions with wine specific ones

by Jeremy Newman

Is this the final version of this patch? Or shall I wait for an updated one from you? On Tue, 2007-09-11 at 11:31 -0700, Lei Zhang wrote: > Hi, > > This is for bug 9110. Hopefully bug reporters will stop marking their > bugs as critical and then get upset when we set it to normal.

Sept. 11, 2007

wordpad: #1 Store bar states in the registry (try 2)

by Alexander Nicolaysen Sørnes

On Tuesday 11 September 2007 21:30:41 you wrote: > Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > > Ok, I see what you mean. I didn't seem all that different from the > > previous behaviour, though. The CLIPCHILDREN patch can be applied before > > the others. > > It's very different, the previous behavior is purely cosmetic, but > with your patch the app becomes unusable as soon as you resize the > window, since the text and toolbar now overlap. Ah, I think I see what you mean. Sorry for all the mess. When all toolbars were hidden the edit control would still be placed as though one of the bars were visible. It would not cause any loss of functionality, though, but it would look like it. That is because of a bug in our rebar code (bug 9450) This version updates the hack for builtin richedit. Alexander N. Sørnes

Sept. 11, 2007

Re: A fix for a problem with older games

by Stefan Dösinger

Am Sonntag, 9. September 2007 17:10:39 schrieb Martin: That patch is not correct Are you sure that this patch really causes a problem? If you are running the game in winedbg and get an exception there it is a symptom of the DIB management in winex11.drv. You can just use "pass" to pass the exception up to the next handler(winex11.drv). The exception never reaches the app. If you really get a crash there then This->resource.allocatedMemory is pointing to a bad location, most likely NULL. This is a problem at some other place and should be fixed elsewhere. This read is a hack to work around a bug in the open source ati driver which caused a hard system crash if an exception occured during glDrawPixels. You can remove hack as a whole if it really causes problems, but this will cause hard crashes for a wide range of radeon drivers(xorg 6.8 and 7.0 at least). I think it is fixed in the latest version, but I am not sure, I'd have to test that. Since the hack is confined in one single function and doesn't have any side effects I decided to keep it.

Sept. 11, 2007

Re: a ddraw patch

by Stefan Dösinger

Am Sonntag, 9. September 2007 17:11:06 schrieb Martin: That patch will obviously break the game the dwTextureCaps modification was added originally... Can you check which cap that game needs that is removed in those lines?

Sept. 11, 2007

Re: wordpad: #1 Store bar states in the registry

by Alexandre Julliard

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > Ok, I see what you mean. I didn't seem all that different from the previous > behaviour, though. The CLIPCHILDREN patch can be applied before the others. It's very different, the previous behavior is purely cosmetic, but with your patch the app becomes unusable as soon as you resize the window, since the text and toolbar now overlap. -- Alexandre Julliard julliard(a)winehq.org

Sept. 11, 2007

Re: wordpad: #1 Store bar states in the registry

by Alexander Nicolaysen Sørnes

On Tuesday 11 September 2007 20:57:17 you wrote: > Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > > Positive; and I tested with Wine 0.9.44 and GIT without my unapplied > > patches. It needs the WS_CLIPCHILDREN style for the main window, which is > > not set. I sent the WS_CLIPCIHLDREN patch to Eric for review, but I > > don't think there is anything wrong with it. > > The flickering exists today, that's true, but with your patch it gets > much worse, the toolbars not only flicker but the edit is actually > resized over the whole window, and the toolbars disappear completely. Ok, I see what you mean. I didn't seem all that different from the previous behaviour, though. The CLIPCHILDREN patch can be applied before the others. Alexander N. Sørnes

Sept. 11, 2007

Re: [bugzilla] replace generic severity descriptions with wine specific ones

by Lei Zhang

On 9/11/07, Juan Lang <juan.lang(a)gmail.com> wrote: > > I'll wait for more feedback and then send another patch. > > If you assume users read the descriptions before choosing a severity, > I think you assume a lot. I suspect most users choose from the list > of words, assigning their own meaning to them. So of course, every > bug becomes a "blocker," because hey, it's blocking me getting my work > done. Modding bugs down, and telling users to vote if they really > care about a bug, is just part of triage. > > --Juan > Some users do read the severity, and they currently see: Critical - crashes, loss of data, severe memory leak so just about anytime Wine crashes, they mark their bugs critical. When we mod the bug down, they get upset and occasionally sparks fly.

Sept. 11, 2007

Re: wordpad: #1 Store bar states in the registry

by Alexandre Julliard

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > Positive; and I tested with Wine 0.9.44 and GIT without my unapplied patches. > It needs the WS_CLIPCHILDREN style for the main window, which is not set. I > sent the WS_CLIPCIHLDREN patch to Eric for review, but I don't think there is > anything wrong with it. The flickering exists today, that's true, but with your patch it gets much worse, the toolbars not only flicker but the edit is actually resized over the whole window, and the toolbars disappear completely. -- Alexandre Julliard julliard(a)winehq.org

Sept. 11, 2007

Re: [bugzilla] replace generic severity descriptions with wine specific ones

by Juan Lang

> I'll wait for more feedback and then send another patch. If you assume users read the descriptions before choosing a severity, I think you assume a lot. I suspect most users choose from the list of words, assigning their own meaning to them. So of course, every bug becomes a "blocker," because hey, it's blocking me getting my work done. Modding bugs down, and telling users to vote if they really care about a bug, is just part of triage. --Juan

Sept. 11, 2007

Re: [bugzilla] replace generic severity descriptions with wine specific ones

by Lei Zhang

On 9/11/07, James Hawkins <truiken(a)gmail.com> wrote: > On 9/11/07, Lei Zhang <thestig(a)google.com> wrote: > > Hi, > > > > This is for bug 9110. Hopefully bug reporters will stop marking their > > bugs as critical and then get upset when we set it to normal. > > > > <th>Blocker</th> > > - <td>Blocks development and/or testing work</td> > + <td>When Wine won't start at all for any application, and there's no work > + around</td> > > I think you've made this too specific, especially for Blocker. For > example, in the new description you've left out compile errors, which > is a big part of what blocker represents. The original description is > fine for blocker. > > <th>Major</th> > > - <td>major loss of function</td> > + <td>For a problem that is affecting most applications you run in Wine</td> > + </tr> > > Why not something like, > > major loss of functionality for a wide range of applications > > instead of totally rewriting the definition. > > -- > James Hawkins > For the most part, I just copy and pasted from the bit at the bottom of http://wiki.winehq.org/Bugs. I'll wait for more feedback and then send another patch.

Sept. 11, 2007

Re: [bugzilla] replace generic severity descriptions with wine specific ones

by James Hawkins

On 9/11/07, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > This is for bug 9110. Hopefully bug reporters will stop marking their > bugs as critical and then get upset when we set it to normal. > <th>Blocker</th> - <td>Blocks development and/or testing work</td> + <td>When Wine won't start at all for any application, and there's no work + around</td> I think you've made this too specific, especially for Blocker. For example, in the new description you've left out compile errors, which is a big part of what blocker represents. The original description is fine for blocker. <th>Major</th> - <td>major loss of function</td> + <td>For a problem that is affecting most applications you run in Wine</td> + </tr> Why not something like, major loss of functionality for a wide range of applications instead of totally rewriting the definition. -- James Hawkins

Sept. 11, 2007

Re: [bugzilla] replace generic severity descriptions with wine specific ones

by Jesse Allen

On 9/11/07, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > This is for bug 9110. Hopefully bug reporters will stop marking their > bugs as critical and then get upset when we set it to normal. > > > > > How about for minor you still keep "where an easy workaround is present". That differentiates it from normal. Jesse

Sept. 11, 2007

Re: Fifa 07 - wined3d regression

by Lei Zhang

Is this bug 9459? [1] If so, please add the regression test results to that bug. Otherwise, open a new bug. [1] http://bugs.winehq.org/show_bug.cgi?id=9459 On 9/10/07, Jan de Mooij <jandemooij(a)gmail.com> wrote: > Hi, > > Fifa 07 used to work fine with Wine, but around version 0.9.40-0.9.41 > the game hangs when I start a new match. The text "Loading..." is > displayed, but there is no progressbar because one thread terminates. > I attached the results of winedbg (backtrace and some messages before > the crash). > > This is the result of git bisect: > > 9ba3f389f665aae45b6a8a6861f9621b020e5c25 is first bad commit > commit 9ba3f389f665aae45b6a8a6861f9621b020e5c25 > Author: Stefan Dösinger <stefandoesinger(a)gmx.at> > Date: Sun Jul 8 23:33:48 2007 +0200 > > wined3d: Initialize surfaces at creation. > > > This patch removes a check of "GL_SUPPORT(APPLE_CLIENT_STORAGE)". If I > put that check in again, the game works like before. The if-condition > evaluates to True now, so it allocates the memory. But it segfaults > there I think. Anyone knows how to fix this? Please let me know if you > need more information. > > Thanks in advance! > > Jan de Mooij > > > > >

Sept. 11, 2007

Re: AppDB entries

by Darragh Bailey

On Thu, Aug 30, 2007 at 05:38:36PM +0200, Alexander Nicolaysen Sørnes wrote: > Torsdag 30 august 2007 13:19, skrev speedator(a)gmx.de: > > Hi, > > sometimes app-entries (like Acrobat Reader) are for series of > > applications and versions for the single applications. Sometimes there > > are app-entries(like Age of Empires) for single applications in a series > > and version-entries for patches, betas, demos etc.. And > > sometimes it is a mixture. > > > > What about making this more clear? Do we need entries for the whole > > series? I think it is important for overview. So what about a new > > structure like "application / version / derived from version(subversion)"? > > > > Julian I think the problem with some of the AppDB entries is more with patches. For many games the subsequent versions after the initial release are treated as separate entries, which is not a good breakdown imho. I think the suggestion would be excellent provided it's only applied to the cases dealing with patched applications/games. I think that keeping the testing information for the different patch levels of apps separate would be useful, but you don't really want to end up with duplicate comments areas covering the same details as well. Whether it would be worth the trouble to add, and whether it would get used is another question. > > There is a difference between games and other applications. Adobe Reader 5 > and 7 are versions of the same program, but say Command & Conquer Tiberian > Sun and Command & Conquer Red Alert are not versions of the same game; they > are very different. > > Alexander N. Sørnes > I think he was suggesting that we treat "Command & Conquer Tiberian Sun" as one series and have any subsequent patches applied to it as being "derived from version(subversion)". i.e. a single entry for the game, with separate sub entries for the different versions due to patching. Although in the case of that game they have one entry for all versions "1.0-2.03". Best of luck working out if you need patches, or whether some of the later patches cause more problems than they fix. You'd have to read through all the comments, rather than just look for the testing details corresponding to the patch level of the game you have installed. -- Darragh "Nothing is foolproof to a sufficiently talented fool."

Sept. 11, 2007

iTunes 7

by Juan Lang

Folks, I just sent a series of wintrust patches that gets iTunes 7 to start, at least for me. I expect some will get rejected due to collision with Francois's patch - I'll resynch and resend. But if you want to play around with iTunes, grab those patches and give them a whirl. Known issues: 1. Your screen will go black when it starts. This is something QuickTime is doing. You can drag windows around to force some repainting to work around it. 2. You'll see lots of fixmes on the console, especially: "fixme:setupapi:CMP_WaitNoPendingInstallEvents 0", "fixme:setupapi:SetupDiGetClassDevsW returning empty list", and "fixme:htmlhelp:HtmlHelpW HH case HH_PRETRANSLATEMESSAGE not handled." 3. The main window will be transparent (and basically unusable) if you don't have GL support compiled in. Have fun, --Juan

Sept. 11, 2007