August 2010 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] dmime/tests: Added tests for IDirectMusicPerformance.

by David Adam

Hello, some comments about this patch + if (hr != S_OK) return FALSE; + else return TRUE; could be simplified as return SUCCEEDED(hr); + trace("HRESULT when creating instance (%x)\n", hr); Since tests are assumed to pass, we dont care about debug informations. So, traces are useless in tests. [It is my opinion. Better developpers could give an opposite opinion] + todo_wine ok(*(ULONG *)pDirectMusicPort != 0, "IDirectMusicPort not set\n"); Why is this cast useful? A+ David 2010/8/9 Austin Lund <austin.lund(a)gmail.com> > > > > >

Aug. 11, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, No more MCIERR_HARDWARE in David's latest test result, hurray! The difference with prior tests is that I temporarily eliminated 3 commands a) resume c b) set c video audio all off c) set c door closed notify We are not done yet. Users who saw that error please feed the following scripts into the mcishell to see which of those 3 commands causes the failure. The mcishell is attached to bug #20232 at http://bugs.winehq.org/show_bug.cgi?id=20232#c10 http://bugs.winehq.org/attachment.cgi?id=24529 wintest.exe mcishell mci.c:1363: Type your commands to the MCI, end with Ctrl-Z The 5 test failures in David's report are unrelated to MCIERR_HARDWARE. >mcicda.c:540: Test failed: status mode after play is playing Weird. I'd have expected Play to terminate within Sleep(3900ms) time. >mcicda.c:297: Test failed: status position initially 00:02:33 I'll take care of that another day. For now I'll just remember that there are disks that don't start at position 00:02:00. Please copy&paste these lines as one piece into a cmd shell so that there's as little delay as possible between commands. # a) resume open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify resume c status c mode seek c to start notify status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c Don't forget after each one close c # b) set video audio open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify seek c to start notify set c video audio all off status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c # c) set door closed open cdaudio alias c notify shareable status c mode status c position play c from 00:02:00 to 00:01:00 notify seek c to start notify set c door closed notify status c mode seek c to end # # testsuite uses seek c to MM:SS:FF instead set c time format tmsf play c from 1 stop c Thank you for testing, Jörg Höhle

Aug. 11, 2010

Re: Request for comments - d3dx9: Add tests for FVF <-> declaration conversion.

by misha680

Stefan Dösinger wrote: > > Hi, > The tests look OK. Since a part of the code was taken from > dlls/d3d9/tests/vertexdeclaration.c(which is OK) you should copy the > copyright lines along as well. > Thanks, how about this guy? I have added the copyright notices. http://wine.1045685.n5.nabble.com/file/n2471349/0001-d3dx9-Add-tests-for-FV… 0001-d3dx9-Add-tests-for-FVF-declaration-conversion.txt I will send to wine-patches pending Henri's approval/ok (as my understanding is that this will be necessary for patch acceptance to GIT - please correct me if I am mistaken). I have cc'ed him on this email. Thank you Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Request-for-comments-d3dx9-Add-tests-for-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 10, 2010

Re: Request for comments - d3dx9: Add tests for FVF <-> declaration conversion.

by Stefan Dösinger

Hi, The tests look OK. Since a part of the code was taken from dlls/d3d9/tests/vertexdeclaration.c(which is OK) you should copy the copyright lines along as well. Am 10.08.2010 um 23:25 schrieb misha680: > > Dear All: > > I have become more busy with schoolwork than I had imagined. > > However, I would still like, if possible, to finish work on > http://bugs.winehq.org/show_bug.cgi?id=22918 > > It has been suggested that I send patches to the wine-devel list first for > feedback. This way, I hope to be able to get developer expertise in these > areas, and to be able to understand exactly what is necessary for a given > patch. > > I have, per this comment from Henri: > http://bugs.winehq.org/show_bug.cgi?id=22918#c51 > written a draft patch for FVF <-> declaration conversion tests. > > It can be found at the Nabble link below. I will appreciate comments as to > what is necessary for this patch (or a similar one) to get accepted. > http://wine.1045685.n5.nabble.com/file/n2471306/0001-d3dx9-Add-tests-for-FV… > 0001-d3dx9-Add-tests-for-FVF-declaration-conversion.txt > > I realize there are already three tests for conversion in one direction. I > have decided at the moment to leave those as is and focus on getting > necessary feedback for getting an appropriate patch accepted. If you have > any guidance with regards to this, much appreciated. > > Thank you > Misha > > p.s. I have uploaded some shell scripts that I use for Wine development > here: > http://groups.google.com/group/misha680-wine/files > I don't know how useful they will be to anyone else, but if anything, it > provides an nice backup for my computer. > -- > View this message in context: http://wine.1045685.n5.nabble.com/Request-for-comments-d3dx9-Add-tests-for-… > Sent from the Wine - Devel mailing list archive at Nabble.com. > >

Aug. 10, 2010

re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Dan Kegel

That's for http://bugs.winehq.org/show_bug.cgi?id=20335 , right? Alexandre's reply to that was "It sounds like it's hashing padding bytes. Probably should be reported to the X.org folks." X is old code, and I don't think anyone has cleaned it up for valgrind yet. That's why I use suppression files like http://winezeug.googlecode.com/svn/trunk/valgrind/valgrind-suppressions which contain blanket suppressions like { bogus_X11_1 Memcheck:Param write(buf) obj:* obj:/usr/lib*/libX11.so.6.2.0 } { bogus_X11_2 Memcheck:Param write(buf) obj:* obj:* obj:/usr/lib*/libX11.so.6.2.0 }

Aug. 10, 2010

Request for comments - d3dx9: Add tests for FVF <-> declaration conversion.

by misha680

Dear All: I have become more busy with schoolwork than I had imagined. However, I would still like, if possible, to finish work on http://bugs.winehq.org/show_bug.cgi?id=22918 It has been suggested that I send patches to the wine-devel list first for feedback. This way, I hope to be able to get developer expertise in these areas, and to be able to understand exactly what is necessary for a given patch. I have, per this comment from Henri: http://bugs.winehq.org/show_bug.cgi?id=22918#c51 written a draft patch for FVF <-> declaration conversion tests. It can be found at the Nabble link below. I will appreciate comments as to what is necessary for this patch (or a similar one) to get accepted. http://wine.1045685.n5.nabble.com/file/n2471306/0001-d3dx9-Add-tests-for-FV… 0001-d3dx9-Add-tests-for-FVF-declaration-conversion.txt I realize there are already three tests for conversion in one direction. I have decided at the moment to leave those as is and focus on getting necessary feedback for getting an appropriate patch accepted. If you have any guidance with regards to this, much appreciated. Thank you Misha p.s. I have uploaded some shell scripts that I use for Wine development here: http://groups.google.com/group/misha680-wine/files I don't know how useful they will be to anyone else, but if anything, it provides an nice backup for my computer. -- View this message in context: http://wine.1045685.n5.nabble.com/Request-for-comments-d3dx9-Add-tests-for-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 10, 2010

Re : Wine users with a CD-ROM drive, please test

by paulo lesgaz

You will attached the results of the tests on my real vista box As the last time, I used the original CD of Police: Greatest hits David ________________________________ De : "Joerg-Cyril.Hoehle(a)t-systems.com" <Joerg-Cyril.Hoehle(a)t-systems.com> À : wine-devel(a)winehq.org Cc : tijnema(a)gmail.com; jeffzaroyko(a)gmail.com; jeremielapuree(a)yahoo.fr; knan-wine(a)anduin.net Envoyé le : Mar 10 août 2010, 17h 50min 39s Objet : Wine users with a CD-ROM drive, please test Hi, http://testbot.winehq.org/JobDetails.pl?Key=4395 contains a new patch and binary where I eliminated a few commands that might cause the MCIERR_HARDWARE observed with the second Seek and first Play, as well as a few more calls to "status c mode" to verify the current state. Thank you for testing, Jörg Höhle

Aug. 10, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)

by Stefan Dösinger

Am 10.08.2010 um 17:42 schrieb Oldrich Jedlicka: > Ok, I understand. I'm just sending the whole patchset with changed/unchanged patches (the number of patches changed, because some of them had been applied and some of them I removed, because they don't implement things properly). Admittedly I didn't look at the other patches, I looked at patches 1-2 and thought that I've seen this in exactly the same form before. In your specific situation it is probably better to send just patch 1, wait until it is applied, then send patch 2, etc, and send bigger patchsets once you've a few patches in Wine. To answer the general questions, this is how I deal with problems in a part of the patchset: *) Generally write a mail stating that the patch is broken and shouldn't be applied to wine-devel. If follow-up patches are independent of this patch I can state so in the mail. If the issue was quick to fix(e.g. whitespace problems) and I am confident that the patch should work now I'll attach the new patch and send the mail to wine-patches only. Otherwise, if I can't attach a fixed patch right away the options are as follows: *) Resend the entire patchset, probably on the following day. *) Let the first patches be applied, resend the remaining patches the next day. Basically it is better to push forward a bit slower and let the patches of the day settle and resend the next day to avoid confusion. Also a (try X) with X > 4 usually often leads to skepticism, because people don't know how many more tries will be needed. I am personally critical of this because of my own experience on gcc-patches. I needed about 10 tries to get the gcc patch for the Steam overlay, I would never have been able to do it with just 4 or 5 iterations. > Is there some recommended way to send updated patchsets when only some patches need to be improved (but the sequence of applying should stay)? Would the "introductionary" mail describing changes and patches as follow-ups help? This can be helpful, but it is also possible to mention what changes you made in the new patch version in the patch description itself. A separate overview description(or description in patch 1) can be helpful if the overall direction of the changes is not easy to understand from the patches themselves, e.g. if more patches are going to come after those are applied. In this situation it is also recommended to send all patches in a packed archive to wine-devel for review, so everyone can see where you're headed.

Aug. 10, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, http://testbot.winehq.org/JobDetails.pl?Key=4395 contains a new patch and binary where I eliminated a few commands that might cause the MCIERR_HARDWARE observed with the second Seek and first Play, as well as a few more calls to "status c mode" to verify the current state. Thank you for testing, Jörg Höhle

Aug. 10, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)

by Oldrich Jedlicka

Hi Stefan, > 10.8.2010 15:40:40, Stefan Dösinger <stefandoesinger(a)gmx.at>: > Diff -u doesn't find any difference between try 4 and try 5, and probably older > tries. If you're resending them because the older ones weren't applied, that's > futile - Alexandre is on vacation. > > Also it is generally a bad idea to keep resending a unchanged patch. If you > think the patch has been lost(e.g. Alexandre is waiting for my review and I am > not at home, etc) it is better to ask on Wine-devel what is up with the > patches. Ok, I understand. I'm just sending the whole patchset with changed/unchanged patches (the number of patches changed, because some of them had been applied and some of them I removed, because they don't implement things properly). Is there some recommended way to send updated patchsets when only some patches need to be improved (but the sequence of applying should stay)? Would the "introductionary" mail describing changes and patches as follow-ups help? Thanks, Oldřich. > Am Sonntag 08 August 2010, 07:09:24 schrieb Oldřich Jedlička: > > --- > > dlls/ddraw/tests/dsurface.c | 138 > > +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 138 > > insertions(+), 0 deletions(-) > > > > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > > index 76bfc7e..8cdcd92 100644 > > --- a/dlls/ddraw/tests/dsurface.c > > +++ b/dlls/ddraw/tests/dsurface.c > > @@ -25,6 +25,7 @@ > > > > #include <assert.h> > > #include "wine/test.h" > > +#include "wine/exception.h" > > #include "ddraw.h" > > #include "d3d.h" > > #include "unknwn.h" > > @@ -3569,6 +3570,142 @@ static void BackBufferAttachmentFlipTest(void) > > DestroyWindow(window); > > } > > > > +static void CreateSurfaceBadCapsSizeTest(void) > > +{ > > + DDSURFACEDESC ddsd_ok; > > + DDSURFACEDESC ddsd_bad1; > > + DDSURFACEDESC ddsd_bad2; > > + DDSURFACEDESC ddsd_bad3; > > + DDSURFACEDESC ddsd_bad4; > > + DDSURFACEDESC2 ddsd2_ok; > > + DDSURFACEDESC2 ddsd2_bad1; > > + DDSURFACEDESC2 ddsd2_bad2; > > + DDSURFACEDESC2 ddsd2_bad3; > > + DDSURFACEDESC2 ddsd2_bad4; > > + IDirectDrawSurface *surf; > > + IDirectDrawSurface4 *surf4; > > + IDirectDrawSurface7 *surf7; > > + HRESULT hr; > > + IDirectDraw2 *dd2; > > + IDirectDraw4 *dd4; > > + IDirectDraw7 *dd7; > > + > > + const DWORD caps = DDSCAPS_OFFSCREENPLAIN; > > + > > + memset(&ddsd_ok, 0, sizeof(ddsd_ok)); > > + ddsd_ok.dwSize = sizeof(ddsd_ok); > > + ddsd_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > > + ddsd_ok.dwWidth = 64; > > + ddsd_ok.dwHeight = 64; > > + ddsd_ok.ddsCaps.dwCaps = caps; > > + memcpy(&ddsd_bad1, &ddsd_ok, sizeof(ddsd_bad1)); > > + ddsd_bad1.dwSize--; > > + memcpy(&ddsd_bad2, &ddsd_ok, sizeof(ddsd_bad2)); > > + ddsd_bad2.dwSize++; > > + memcpy(&ddsd_bad3, &ddsd_ok, sizeof(ddsd_bad3)); > > + ddsd_bad3.dwSize = 0; > > + memcpy(&ddsd_bad4, &ddsd_ok, sizeof(ddsd_bad4)); > > + ddsd_bad4.dwSize = sizeof(DDSURFACEDESC2); > > + > > + memset(&ddsd2_ok, 0, sizeof(ddsd2_ok)); > > + ddsd2_ok.dwSize = sizeof(ddsd2_ok); > > + ddsd2_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > > + ddsd2_ok.dwWidth = 64; > > + ddsd2_ok.dwHeight = 64; > > + ddsd2_ok.ddsCaps.dwCaps = caps; > > + memcpy(&ddsd2_bad1, &ddsd2_ok, sizeof(ddsd2_bad1)); > > + ddsd2_bad1.dwSize--; > > + memcpy(&ddsd2_bad2, &ddsd2_ok, sizeof(ddsd2_bad2)); > > + ddsd2_bad2.dwSize++; > > + memcpy(&ddsd2_bad3, &ddsd2_ok, sizeof(ddsd2_bad3)); > > + ddsd2_bad3.dwSize = 0; > > + memcpy(&ddsd2_bad4, &ddsd2_ok, sizeof(ddsd2_bad4)); > > + ddsd2_bad4.dwSize = sizeof(DDSURFACEDESC); > > + > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_ok, &surf, NULL); > > + ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > > + IDirectDrawSurface_Release(surf); > > + > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad1, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad2, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad3, &surf, NULL); > > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return > > 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad4, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + > > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw2, (void **) > > &dd2); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > > 0x%08x\n", hr); + > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_ok, &surf, NULL); > > + ok(SUCCEEDED(hr), "IDirectDraw2_CreateSurface failed: 0x%08x\n", hr); > > + IDirectDrawSurface_Release(surf); > > + > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad1, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad2, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad3, &surf, NULL); > > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface didn't > > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad4, &surf, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + > > + IDirectDraw2_Release(dd2); > > + > > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw4, (void **) > > &dd4); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > > 0x%08x\n", hr); + > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_ok, &surf4, NULL); > > + ok(SUCCEEDED(hr), "IDirectDraw4_CreateSurface failed: 0x%08x\n", hr); > > + IDirectDrawSurface4_Release(surf4); > > + > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad1, &surf4, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad2, &surf4, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad3, &surf4, NULL); > > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface didn't > > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad4, &surf4, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + > > + IDirectDraw4_Release(dd4); > > + > > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw7, (void **) > > &dd7); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > > 0x%08x\n", hr); + > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_ok, &surf7, NULL); > > + ok(SUCCEEDED(hr), "IDirectDraw7_CreateSurface failed: 0x%08x\n", hr); > > + IDirectDrawSurface7_Release(surf7); > > + > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad1, &surf7, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad2, &surf7, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad3, &surf7, NULL); > > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface didn't > > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad4, &surf7, NULL); > > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > > + > > + IDirectDraw7_Release(dd7); > > +} > > + > > START_TEST(dsurface) > > { > > HRESULT ret; > > @@ -3624,5 +3761,6 @@ START_TEST(dsurface) > > GetDCFormatTest(); > > BackBufferCreateSurfaceTest(); > > BackBufferAttachmentFlipTest(); > > + CreateSurfaceBadCapsSizeTest(); > > ReleaseDirectDraw(); > > } > > > > > >

Aug. 10, 2010

Re: X Presentation and Synchronization - will it help Wine performance

by Roderick Colenbrander

On Tue, Aug 10, 2010 at 6:53 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 10 August 2010 15:27, Groeschel, Volker <volker.groeschel(a)sap.com> wrote: >> I wonder if Wine will profit from the new X Presentation and Synchronization >> feature NVIDIA is working on: >> >> >> >> http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization… >> > I doubt it, unless it will somehow make the drivers themselves faster. > >> e.g. when I start several instances of my game with Wine on my computer (AMD >> X2 with Ubuntu and proprietary NVIDIA graphic drivers), performance breaks >> down dramatically. >> > Yeah, that's a fairly well known issue with the nvidia drivers, you > can also see that when e.g. comparing fps from running two glxgears > instances with running just a single instance. Running two instances > at the same time will get you much less than half the performance. > That issue may be unique to nvidia's setup, I don't get it with the > free r600 driver. Though it should be said that performance there > isn't quite at the level where it's fair to compare yet. > > > In my experience on Nvidia Fermi hardware performance scales linearly at least in modern shader limited applications like the Heaven benchmark. In four instances at relatively heavy settings, (I believe each was running at 1024x768 or higher) the fps is fps/4 and by adding each window I saw a linear drop. I don't remember for sure but I think I saw the same on games on Wine, though I would have to recheck it. Older non-Fermi hardware didn't seem to scale as well, but I haven't done that much testing on those GPUs. Yesterday I talked with Nvidia guys and they also said that typically performance should scale linearly but there can be exceptions in which some things might be time sliced. I might be able to do some more testing and if it shows anything interesting I will reply here. Roderick

Aug. 10, 2010

Re: X Presentation and Synchronization - will it help Wine performance

by Henri Verbeet

On 10 August 2010 15:27, Groeschel, Volker <volker.groeschel(a)sap.com> wrote: > I wonder if Wine will profit from the new X Presentation and Synchronization > feature NVIDIA is working on: > > > > http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization… > I doubt it, unless it will somehow make the drivers themselves faster. > e.g. when I start several instances of my game with Wine on my computer (AMD > X2 with Ubuntu and proprietary NVIDIA graphic drivers), performance breaks > down dramatically. > Yeah, that's a fairly well known issue with the nvidia drivers, you can also see that when e.g. comparing fps from running two glxgears instances with running just a single instance. Running two instances at the same time will get you much less than half the performance. That issue may be unique to nvidia's setup, I don't get it with the free r600 driver. Though it should be said that performance there isn't quite at the level where it's fair to compare yet.

Aug. 10, 2010

Re: New and subtle ddraw:dsurface test failure

by Stefan Dösinger

Am Montag 09 August 2010, 21:41:18 schrieb Oldřich Jedlička: > ok(hr==DD_OK || broken(hr != DD_OK && SUCCEEDED(hr)), > "text...") I think as long as no native app is found that depends on DD_OK it's ok just use ok(SUCCEEDED(hr)) for the sake of readability.

Aug. 10, 2010

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5)

by Stefan Dösinger

Diff -u doesn't find any difference between try 4 and try 5, and probably older tries. If you're resending them because the older ones weren't applied, that's futile - Alexandre is on vacation. Also it is generally a bad idea to keep resending a unchanged patch. If you think the patch has been lost(e.g. Alexandre is waiting for my review and I am not at home, etc) it is better to ask on Wine-devel what is up with the patches. Am Sonntag 08 August 2010, 07:09:24 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/dsurface.c | 138 > +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 138 > insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > index 76bfc7e..8cdcd92 100644 > --- a/dlls/ddraw/tests/dsurface.c > +++ b/dlls/ddraw/tests/dsurface.c > @@ -25,6 +25,7 @@ > > #include <assert.h> > #include "wine/test.h" > +#include "wine/exception.h" > #include "ddraw.h" > #include "d3d.h" > #include "unknwn.h" > @@ -3569,6 +3570,142 @@ static void BackBufferAttachmentFlipTest(void) > DestroyWindow(window); > } > > +static void CreateSurfaceBadCapsSizeTest(void) > +{ > + DDSURFACEDESC ddsd_ok; > + DDSURFACEDESC ddsd_bad1; > + DDSURFACEDESC ddsd_bad2; > + DDSURFACEDESC ddsd_bad3; > + DDSURFACEDESC ddsd_bad4; > + DDSURFACEDESC2 ddsd2_ok; > + DDSURFACEDESC2 ddsd2_bad1; > + DDSURFACEDESC2 ddsd2_bad2; > + DDSURFACEDESC2 ddsd2_bad3; > + DDSURFACEDESC2 ddsd2_bad4; > + IDirectDrawSurface *surf; > + IDirectDrawSurface4 *surf4; > + IDirectDrawSurface7 *surf7; > + HRESULT hr; > + IDirectDraw2 *dd2; > + IDirectDraw4 *dd4; > + IDirectDraw7 *dd7; > + > + const DWORD caps = DDSCAPS_OFFSCREENPLAIN; > + > + memset(&ddsd_ok, 0, sizeof(ddsd_ok)); > + ddsd_ok.dwSize = sizeof(ddsd_ok); > + ddsd_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd_ok.dwWidth = 64; > + ddsd_ok.dwHeight = 64; > + ddsd_ok.ddsCaps.dwCaps = caps; > + memcpy(&ddsd_bad1, &ddsd_ok, sizeof(ddsd_bad1)); > + ddsd_bad1.dwSize--; > + memcpy(&ddsd_bad2, &ddsd_ok, sizeof(ddsd_bad2)); > + ddsd_bad2.dwSize++; > + memcpy(&ddsd_bad3, &ddsd_ok, sizeof(ddsd_bad3)); > + ddsd_bad3.dwSize = 0; > + memcpy(&ddsd_bad4, &ddsd_ok, sizeof(ddsd_bad4)); > + ddsd_bad4.dwSize = sizeof(DDSURFACEDESC2); > + > + memset(&ddsd2_ok, 0, sizeof(ddsd2_ok)); > + ddsd2_ok.dwSize = sizeof(ddsd2_ok); > + ddsd2_ok.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2_ok.dwWidth = 64; > + ddsd2_ok.dwHeight = 64; > + ddsd2_ok.ddsCaps.dwCaps = caps; > + memcpy(&ddsd2_bad1, &ddsd2_ok, sizeof(ddsd2_bad1)); > + ddsd2_bad1.dwSize--; > + memcpy(&ddsd2_bad2, &ddsd2_ok, sizeof(ddsd2_bad2)); > + ddsd2_bad2.dwSize++; > + memcpy(&ddsd2_bad3, &ddsd2_ok, sizeof(ddsd2_bad3)); > + ddsd2_bad3.dwSize = 0; > + memcpy(&ddsd2_bad4, &ddsd2_ok, sizeof(ddsd2_bad4)); > + ddsd2_bad4.dwSize = sizeof(DDSURFACEDESC); > + > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_ok, &surf, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface_Release(surf); > + > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad1, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad2, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad3, &surf, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface didn't return > 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw_CreateSurface(lpDD, &ddsd_bad4, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw2, (void **) > &dd2); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_ok, &surf, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw2_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface_Release(surf); > + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad1, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad2, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad3, &surf, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd_bad4, &surf, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw2_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw2_Release(dd2); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw4, (void **) > &dd4); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_ok, &surf4, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw4_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface4_Release(surf4); > + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad1, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad2, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad3, &surf4, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2_bad4, &surf4, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw4_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw4_Release(dd4); > + > + hr = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw7, (void **) > &dd7); + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: > 0x%08x\n", hr); + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_ok, &surf7, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw7_CreateSurface failed: 0x%08x\n", hr); > + IDirectDrawSurface7_Release(surf7); > + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad1, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad2, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad3, &surf7, NULL); > + ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface didn't > return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2_bad4, &surf7, NULL); > + todo_wine ok(hr == DDERR_INVALIDPARAMS, "IDirectDraw7_CreateSurface > didn't return 0x%08x, but 0x%08x\n", + DDERR_INVALIDPARAMS, hr); > + > + IDirectDraw7_Release(dd7); > +} > + > START_TEST(dsurface) > { > HRESULT ret; > @@ -3624,5 +3761,6 @@ START_TEST(dsurface) > GetDCFormatTest(); > BackBufferCreateSurfaceTest(); > BackBufferAttachmentFlipTest(); > + CreateSurfaceBadCapsSizeTest(); > ReleaseDirectDraw(); > }

Aug. 10, 2010

X Presentation and Synchronization - will it help Wine performance

by Groeschel, Volker

Hi, I wonder if Wine will profit from the new X Presentation and Synchronization feature NVIDIA is working on: http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization… According to the Phoronix article the feature is planed for X.Org Server 1.10: http://www.phoronix.com/scan.php?page=news_item&px=ODM3Ng e.g. when I start several instances of my game with Wine on my computer (AMD X2 with Ubuntu and proprietary NVIDIA graphic drivers), performance breaks down dramatically. As of three instances the third windows freezes or gets near 0 FPS while the same computer with Win XP can run up to eight instances. Many thanks for your good work which helps me to get rid of Windows in my home office ☺

Aug. 10, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Eric Pouech wrote: >may be the driver doesn't support TMSF, and from/to fields must be provided in MSF >would you mind trying that ? Me? The others ;) The 5 machines I've had access to all pass the tests. I somehow doubt it'll help because Jeff Zaroyko wrote: >> set c time format tmsf >> seek c to start >> play c from 1 to 2 wait >This works - I hear music. So TMSF works for Jeff, even though the testsuite yields MCIERR_HARDWARE there. Furthermore the failing Seek before Play uses MSF in the proposed testsuite. Nevertheless worth a try. Any hint may work. Perhaps also add the "wait" flag to the tests: seek c to start notify WAIT Perhaps the cause is one of the unusual commands: set c video audio all off set c door closed notify # # Perhaps add status c mode after that? On some machines, inserting an audio CD starts the media player. Perhaps this interacts with the tests? Thank you for your help, Jörg Höhle

Aug. 10, 2010

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Michael Stefaniuc

Hello Austin, Austin Lund wrote: > On 10 August 2010 18:05, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> Hello Austin, >> >> Austin Lund wrote: >>> ------------------------------------------------------------------------ > >> both functions are heavily used and you don't want to waste time >> HEAP_ZERO_MEMORY just to please valgrind. I even wonder why valgrind >> complains as e.g. in X11DRV_SetBitmapBits() only the default switch case >> won't initialize the memory at all. > > Thanks for the comment. I ran winemine in valgrind to get this. > Somehow that must trigger the default case. no, you would see a FIXME in that case. I wonder if Dan Kegel might know more on why valgrind triggers in that case. bye michael

Aug. 10, 2010

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Austin Lund

On 10 August 2010 18:05, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Hello Austin, > > Austin Lund wrote: >> >> ------------------------------------------------------------------------ > both functions are heavily used and you don't want to waste time > HEAP_ZERO_MEMORY just to please valgrind. I even wonder why valgrind > complains as e.g. in X11DRV_SetBitmapBits() only the default switch case > won't initialize the memory at all. Hi Michael, Thanks for the comment. I ran winemine in valgrind to get this. Somehow that must trigger the default case.

Aug. 10, 2010

Re: winex11.drv: Fix uninitialised values. (valgrind) (try 2)

by Michael Stefaniuc

Hello Austin, Austin Lund wrote: > > ------------------------------------------------------------------------ > From 07bc18edc35c68c8e0da58a70ccd5c8f03584a1a Mon Sep 17 00:00:00 2001 > From: Austin Lund <austin.lund(a)gmail.com> > Date: Tue, 10 Aug 2010 13:03:14 +1000 > Subject: [PATCH] winex11.drv: Fix uninitialised values. (valgrind) > > --- > dlls/winex11.drv/bitmap.c | 2 +- > dlls/winex11.drv/dib.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/winex11.drv/bitmap.c b/dlls/winex11.drv/bitmap.c > index 4683fd9..af6c00b 100644 > --- a/dlls/winex11.drv/bitmap.c > +++ b/dlls/winex11.drv/bitmap.c > @@ -351,7 +351,7 @@ LONG CDECL X11DRV_SetBitmapBits( HBITMAP hbitmap, const void *bits, LONG count ) > wine_tsx11_lock(); > image = XCreateImage( gdi_display, visual, physBitmap->pixmap_depth, ZPixmap, 0, NULL, > bitmap.bmWidth, height, 32, 0 ); > - if (!(image->data = HeapAlloc( GetProcessHeap(), 0, image->bytes_per_line * height ))) > + if (!(image->data = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, image->bytes_per_line * height ))) > { > WARN("No memory to create image data.\n"); > XDestroyImage( image ); > diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c > index 11157f1..eda064e 100644 > --- a/dlls/winex11.drv/dib.c > +++ b/dlls/winex11.drv/dib.c > @@ -3535,7 +3535,7 @@ static int X11DRV_DIB_SetImageBits( const X11DRV_DIB_IMAGEBITS_DESCR *descr ) > else { > bmpImage = XCreateImage( gdi_display, visual, descr->depth, ZPixmap, 0, NULL, > descr->infoWidth, lines, 32, 0 ); > - bmpImage->data = HeapAlloc( GetProcessHeap(), 0, lines * bmpImage->bytes_per_line ); > + bmpImage->data = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, lines * bmpImage->bytes_per_line ); > if(bmpImage->data == NULL) { > ERR("Out of memory!\n"); > XDestroyImage( bmpImage ); > both functions are heavily used and you don't want to waste time HEAP_ZERO_MEMORY just to please valgrind. I even wonder why valgrind complains as e.g. in X11DRV_SetBitmapBits() only the default switch case won't initialize the memory at all. bye michael

Aug. 10, 2010

Re: New and subtle ddraw:dsurface test failure

by Oldřich Jedlička

Hi W, On Monday 09 August 2010 12:31:45 wylda(a)volny.cz wrote: > Hi, > > > Do you mean this problem? > > ddraw:dsurface start ... > > Nope and nothing about 64bit (there was no change). I was initially > talking about changed result from last Friday. To be precise this > new information showed up under WinXP 32bit on nvidia 8600GT: > > > dsurface.c:3511: Test failed: IDirectDrawSurface_Flip returned > 0x00000003 > dsurface.c:3528: Test failed: IDirectDrawSurface_Flip returned > 0x00000003 > > And i had a slight feeling, that i saw you, Oldrich, doing some > changes in this are. Thus decided to substitute "paranoid android" > aka testbot(a)testbot.winehq.org. > > Last note, intel card i915gm does not fail on this "Surface_Flip" > and thus i decided to pinpoint this issue for nvidia. Ah, now I see (just describe the full problem the first time, I don't have a witch ball :-)). The nvidia driver doesn't return DD_OK like it should (see http://msdn.microsoft.com/en-us/library/aa915446.aspx) but other non-error code. I cannot say if this is somehow/totally wrong, but for the test purposes this can be work-around by changing the mentioned "ok" line to something like ok(hr==DD_OK || broken(hr != DD_OK && SUCCEEDED(hr)), "text...") This tells the wine to be correct (hr==DD_OK), but allows windows tests to fail with the alternative result code. Could you please try it/test it? Thanks, Oldřich. > > > Regards, > W.

Aug. 9, 2010

Re: [PATCH] quartz: implement AsyncReader_FindPin

by Anton Khirnov

On Sat, Aug 07, 2010 at 11:53:36AM +0200, David Adam wrote: > Hi, > > what about if ppPin is NULL? then it will crash spectacularly, which is exactly what the client throwing around invalid pointers deserves ;) the surrounding code assumes that it's passed valid pointers too. anyway, dshow seems to require this, so added a check locally > I think that this patch needs test cases to prove that it is correct? I'll try to write something, but i'm not familiar with wine/quartz API (i just wanted to get video playback in a game working :) ) so it might be problematic. anyway, i've looked around some more and it seems that this function can be shared for all IBaseFilter subclasses. same probably goes for some other, e.g. IBaseFilter_EnumPins. is there a reason they're not? Anton Khirnov

Aug. 9, 2010

Re: Wine users with a CD-ROM drive, please test

by Eric Pouech

Jörg-Cyril : may be the driver doesn't support TMSF, and from/to fields must be provided in MSF would you mind trying that ? A+ -- -- Eric Pouech

Aug. 9, 2010

Re: Should we expect Liberation fonts to be installed?

by Brian Vincent

On Sun, Aug 8, 2010 at 8:58 PM, Scott Ritchie <scott(a)open-vote.org> wrote: >> This might work for Linux, but these fonts are not installed on any >> MacOSX version that I'm aware of. This might break Wine useage for >> Macs. It might also break it for Solaris as well. > > It should only break in a way that makes it as bad as it currently is. Macs should already have the proper fonts installed, but it might take some config changes to use them properly. Seems more like a packaging issue. Along those lines, the hard drive space is cheap on this one. Seems like Wine packagers could just include the fonts and install them locally in c:\windows\fonts. More properly, we should probably try to detect a system installation of them since it'll probably exist and then fall back on installing them if it doesn't. Fonts are a pretty big usability issue, apps really don't behave properly without them. -Brian

Aug. 9, 2010

Wine users with a CD-ROM drive, please test

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Thank you for your test results so far. >>>mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: MCIERR_HARDWARE >>>mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE >> Same as Jeff, please see if one of you can identify which prior MCI command causes this. >Do you have any instructions how I can identify this? This sequence of commands worked for Jeff: open cdaudio alias c status c type track 1 set c time format tmsf seek c to start play c from 1 to 2 wait The sequence of commands that the tests use is below. I don't see anything there that explains MCIERR_HARDWARE. Perhaps it's a timing issue and the suite would work after adding a couple of Sleep()? Copy&Paste of this sequence into the mcishell (see bug 20232, comment #10) works for me. Does it generate MCIERR_HARDWARE on your machine? Can you try and eliminate commands until you reach a minimal set that generates the error (start with removing capability, info and notify)? open cdaudio alias c notify shareable capability c has video notify capability c can play capability c capability c 16385 capability c device type status c time format info c product wait notify status c media present status c mode status c mode status c ready info c product identity info c identity info c upc status c number of tracks status c length status c position status c position start notify status c position start track 1 notify play c from 00:02:00 to 00:01:00 notify resume c seek c wait seek c to start notify # # Perhaps use seek c to start notify wait set c video audio all off set c time format ms status c position start status c position start track 1 status c notify wait status c length track 1 set c door closed notify status c type track 1 # # skipping data track tests set c time format msf status c length track 20 # # Replace 20 with number of tracks here status c position track 20 # # Perhaps add status c mode (still seeking?) seek c to 24:55:74 # # Replace with position last track start + length seek c to 24:56:00 set c time format tmsf play c from 1 Thank you for your help, Jörg Höhle

Aug. 9, 2010

Re: winepath bug without arguments?

by Paul Chitescu

On Monday 09 August 2010 01:23:24 pm Jerome Leclanche wrote: > Hi > > After fixing a bug in MPQEdit related to opening directories, I > noticed winepath returns a different result with and without quotes: > > adys(a)azura:~/.wine/drive_c$ winepath -w > adys(a)azura:~/.wine/drive_c$ winepath -w "" > C:\ > > With quotes it returns the current directory. Is that intended? If not > I'll open a bug... > > > > J. Leclanche Yes, it's intended. winepath converts zero or more arguments. An empty argument means "start from current dir... and print!" [paulc(a)bussard drive_c]$ winepath -w "" users "Program Files" C:\ C:\users C:\Program Files Paul

Aug. 9, 2010