April 2009 - Wine-devel - list.winehq.org

Re: try5 [1/4](resend) kernel32/tests: Add tests for GetVolumeInformationA and QueryDosDevice
by Paul Vriens 29 Apr '09

29 Apr '09

Guy Albertelli wrote: > Fixed memory leak and changed skip to win_skip in this patch. > Add todo_wine as necessary so all tests pass. > > Changelog: > - Enhance QueryDosDevice test for attempting to return all devices. > - Add tests for GetVolumeInformationA testing the different root dir formats. > --- > dlls/kernel32/tests/volume.c | 138 ++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 134 insertions(+), 4 deletions(-) > > > > ------------------------------------------------------------------------ > > One of the tests fails on all W2K, XP and W2K3 boxes (no Vista results yet): http://test.winehq.org/data/tests/kernel32:volume.html Could you have a look? There is also a lot of trace/debugging information coming from these new tests. Is this needed? -- Cheers, Paul.

2 3

Re: winedbg: Accept a 3rd parameter to --auto to be used as extra info in the crash dialog
by Eric Pouech 29 Apr '09

29 Apr '09

Paul Chitescu a écrit : > Changelog: > winedbg: Accept a 3rd parameter to --auto to be used as extra info in the > crash dialog > > Next patch will actually send this info to the debugger from kernel32. > > ------------------------------------------------------------------------ > > this is not necessary to pass the information to winedbg, everything's needed is accessible from winedbg see tgt_active.c / dbg_handle_exception A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

GL_APPLE_FENCE shares the same token in dlls/wined3d_gl.h with GL_FENCE_STATUS_NV.
by ace102 29 Apr '09

29 Apr '09

Hi, I noticed GL_APPLE_FENCE shares the same token in dlls/wined3d_gl.h with GL_FENCE_STATUS_NV. GL_FENCE_STATUS_NV http://www.opengl.org/registry/specs/NV/fence.txt Currently 0x84F3 GL_APPLE_FENCE http://www.opengl.org/registry/specs/APPLE/fence.txt Currently 0x84F3 Should be 0x8A0B from documentation. Is this by design or just something that slipped through the cracks? Thought I should alert someone just in case.:) Thanks. ----- Error:Success -- View this message in context: http://www.nabble.com/GL_APPLE_FENCE-shares-the-same-token-in-dlls-wined3d_… Sent from the Wine - Devel mailing list archive at Nabble.com.

4 3

Re: Sound problems with latest kernel -- formerly a pulseaudio thread but not any more
by Susan Cragin 29 Apr '09

29 Apr '09

>2009/4/29 Susan Cragin <susancragin(a)earthlink.net>: >> I have tested the following and I believe found they were not the problem: >--snip-- >> (3) problem with pulseaudio > >How did you determine this? I thought you said your version of Ubuntu >was crippled if pulseaudio was removed, so did you use pasuspender? If >so, did you verify there was no pulseaudio process running while you >were testing Wine? After I started my testing, I did run into problems when I tried to re-install pulseaudio and then remove it, but the PA problem was unrelated. Ubuntu said there was a PA bug, and issued a fix. After I applied the fix, no more problems working with pulseaudio removed. So the whole thing was sort of a red herring. I have re-installed my entire system since that problem went away, and immediately purged pulseaudio, and that's where I'm working from now. Still same problem. Susan

2 1

Sound problems with latest kernel -- formerly a pulseaudio thread but not any more
by Susan Cragin 29 Apr '09

29 Apr '09

I'm changing the name of the thread. Pulseaudio has nothing to do with my current problem. I thought it did back when I started the thread, but my testing turned out to be incomplete. I still don't know what the problem is, but I believe it has to do with the way wine relates to the current Ubuntu configuration. Using the most current kernel, the most current updates (and using tomorrow's kernels and updates) dmix and dsnoop I believe are not recognized properly by wine because I'm not getting any sound through them. And I did file a bug, but I filed it back when I still thought it was a wine regression, so it's been a long and painful process of discovery. I have tested the following and I believe found they were not the problem: (1) wine regression: (2) problem with my experimental sound drivers; (3) problem with pulseaudio; (4) bizarre problem unique to me -- and for this I reinstalled the system an tested with the base before moving on. When I did the last install, with the current Ubuntu Studio, I got the same result using the downloaded Generic kernel. (Studio can use both Generic and Real-time kernels. Linux-rt didn't work for other reasons. It crashed on bootup.) I was informed that both then-current kernels had problems. So I got the linux-generic with current Ubuntu patches and a successful re-compile of the linux-rt without Ubuntu patches. And I still have exactly the same problem. Here are my current kernels: linux-rt: 2.6.29.1-rt8-custom (It doesn't include Ubuntu's patches.) linux-generic 2.6.28-12 (this is from the Ubuntu site and has Ubuntu's patches) When I run audacity through wine, I get the following input choices: MIME: Wine wave in mapper - Input MIME: dsnoop:Generic MIME: dsnoop:Generic Windows DirectSound: Primary Sound Capture Driver Windows DirectSound: dsnoop:Generic Windows DirectSound: dsnoop:Generic When I use the second option (MME: dsnoop:Generic) it works on the first pass, but when I try to stop and start it again -- no go. The second recording area pops up but it seems to "shimmer." The recording meter does not move. And then it freezes. (That is approximately what happens to me training DNS.) When I use the 5th option (Windows DirectSound: dsnoop:generic) it works on the first pass, but when I stop/start it I get the following error message: Error when opening sound device. Please check the input device settings and the project sample rate.

2 1

Mmap/malloc redirection (bug 13335, seems to affect 3D games mainly)
by Paul TBBle Hampson 29 Apr '09

29 Apr '09

Bug 13335 [1] is basically "OpenGL games crash or run slow". There's two symptoms here, and they're to do with proprietary video drivers. When the nVidia driver fails to mmap stuff from /dev/nvidia0, it starts failing OpenGL commands with GL_OUT_OF_MEMORY. When the FireGL driver fails to mmap or malloc (I don't know which), it falls back to indrect rendering. The problem in both cases is because Wine mmaps most of the 32-bit memory space for itself and then parcels this back out through HeapAlloc and related methods. When the GL libraries calls mmap and malloc themselves, for quite large blocks of memory, they fail because there's nowhere in the address space for those large blocks of memory to go. The first linked patch [2] in bug 13335 fixes this by redirecting mmap calls into ntdll which unmaps a block of address space, and performs the mmap into that address space, effectively handing that address space over to the library for the duration of the mmap's existence. I can't claim credit for that, I merely took Thunderbird's forward-ported version of Alexandre's original patch and forward-ported it further to 1.1.19. The second linked patch [3] simply redirects malloc and related calls to RtlAllocateHeap, rather like the msvcrt malloc-type calls are handled. The latter's almost certainly in the wrong place in ntdll, but it keeps ntdll from needing two copies of the pthread_functions structure. The bug's staring to accumulate some feedback that this helps for games that otherwise tend to crash after playing for a little while, and I've not had any luck catching people on IRC to look over the patches, so I'm wondering if anyone would like to provide feedback on these patches, as to whether they are the right approach, and if there are things that could be handled more cleanly. [1] http://bugs.winehq.org/show_bug.cgi?id=13335 [2] http://bugs.winehq.org/attachment.cgi?id=20483 [3] http://bugs.winehq.org/attachment.cgi?id=20484 -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

1 0

The DIB engine... does anyone know how to get it into Wine?
by Luke Benstead 29 Apr '09

29 Apr '09

Hi all, I've been watching the DIB engine work that has been going on in bug 421. It looks like Max has made massive progress getting Autocad working by the sound of it, almost perfectly and also improvements in Starcraft have been reported. However, he accepts (and Alexandre has confirmed) that neither of the two approaches he has tried is the right one and he believes (as do others) that any correct approach requires massive changes to GDI32, which if I read it right, no one seems to know how to do incrementally. Autocad is one of those apps, like Photoshop, which people need to be able to use and won't switch away from Windows without it. In fact, Autocad more so than Photoshop because there is no (almost) feature equivalent alternative available (like the GIMP for Photoshop). So it's frustrating to know that someone has it working, but vanilla Wine isn't going to see it working in the near future. My question is this: does anyone know how to incrementally implement the necessary changes? Is it even possible? If it's not possible, is it work considering branching Wine to implement it correctly, for merging back into trunk at a later stage once it's been thoroughly tested? I'm wondering if Wine's development process just doesn't allow for a big change like this, and perhaps it's the development model that is the reason bug 421 is so long standing? Any thoughts, I just want to spur some discussion on this because it seems that everyone that attempts a DIB engine hits a wall :) Luke.

9 16

Re: gdiplus: Implement GdipCreateHBITMAPFromBitmap
by Nikolay Sivov 29 Apr '09

29 Apr '09

Massimo Del Fedele wrote: > Massimo Del Fedele ha scritto: >> Should work for both DIBs and DDBs format, but strange enough the >> IPicture bitmap >> inside wine gdiplus bitmap is always a 32 bit DDB by now... haven't >> found any >> other case. >> >> Ciao >> >> Max >> >> >> ------------------------------------------------------------------------ >> >> > sorry again... another dumb copy/paste :-( > Former had a spurious FIXME used for debugging purposes > > Max + IPicture_get_Handle(bitmap->image.picture, (OLE_HANDLE*)&hbm); + if(!hbm) + /* FIXME: return appropriate error code */ + return GenericError; + + /* gets bitmap data and find out bitmap's type */ + if(!(size = GetObjectW(hbm, sizeof(DIBSECTION), &ds))) + { + ERR("Couldn't get bitmap data\n"); + return GenericError; + } Could be HICON here (see GdipCreateBitmapFromHICON) or metafile. Since there's no tests for that could you please an explicit FIXME for that types?

2 1

Re: try5 [4/4](resend) kernel32: Fix GetVolumeNameForVolumeMountPointW to match Mountmgr
by Alexandre Julliard 29 Apr '09

29 Apr '09

Guy Albertelli <galberte(a)neo.rr.com> writes: > mountmgr.sys uses a specific format for "unique volume name". Make > GetVolumeNameForVolumeMountPointW match that format for the returned > unique volume name. It should actually query mountmgr, not try to guess the name that mountmgr is using. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/3] iphlpapi: Add tests for GetAdaptersAddresses.
by Paul Vriens 29 Apr '09

29 Apr '09

Hans Leidekker wrote: > diff --git a/dlls/iphlpapi/tests/iphlpapi.c b/dlls/iphlpapi/tests/iphlpapi.c > index 2fc5e0d..a03cc85 100644 > +static void test_GetAdaptersAddresses(void) > +{ > + ULONG ret, size; > + IP_ADAPTER_ADDRESSES *aa; > + IP_ADAPTER_UNICAST_ADDRESS *ua; > + > + if (!gGetAdaptersAddresses) return; Could you add a win_skip()? -- Cheers, Paul.

1 0