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

Re: [PATCH 6/8] wscript: implemented Host_put_Interactive (resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12933 Your paranoid android. === W7PROX64 (32 bit) === run.c:177: Test failed: test.JS: L"WScript.FullName = " run.c:177: Test failed: test.JS: L"WScript.Path = "

July 27, 2011

Re: [PATCH 5/8] wscript: implemented Host_get_Interactive (resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12932 Your paranoid android. === W7PROX64 (32 bit) === run.c:177: Test failed: test.JS: L"WScript.FullName = " run.c:177: Test failed: test.JS: L"WScript.Path = "

July 27, 2011

Re: [PATCH 4/8] wscript: implemented Arguments2_get_length (resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12931 Your paranoid android. === W7PROX64 (32 bit) === run.c:177: Test failed: test.JS: L"WScript.FullName = " run.c:177: Test failed: test.JS: L"WScript.Path = "

July 27, 2011

Re: [PATCH 3/8] wscript: implemented Arguments2_Count (resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12930 Your paranoid android. === W7PROX64 (32 bit) === run.c:177: Test failed: test.JS: L"WScript.FullName = " run.c:177: Test failed: test.JS: L"WScript.Path = "

July 27, 2011

Re: patch for dlls/gdi32/dib.c: fixes crash

by Octavian Voicu

On Wed, Jul 27, 2011 at 6:44 PM, Wolfgang Walter <wine(a)stwm.de> wrote: > - char src_bmibuf[FIELD_OFFSET( BITMAPINFO, bmiColors[256] )]; > - BITMAPINFO *src_info = (BITMAPINFO *)src_bmibuf; > - char dst_bmibuf[FIELD_OFFSET( BITMAPINFO, bmiColors[256] )]; > - BITMAPINFO *dst_info = (BITMAPINFO *)dst_bmibuf; There's another instance of that in GetDIBits. Allocating 2KB+ (2 x 1064 bytes) of data on the stack is not very reasonable I guess. Octavian

July 27, 2011

Re: [PATCH 1/8] wscript: added arguments.c; implemented Host_get_Arguments (try 2)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=12928 Your paranoid android. === W7PROX64 (32 bit) === run.c:177: Test failed: test.JS: L"WScript.FullName = " run.c:177: Test failed: test.JS: L"WScript.Path = "

July 27, 2011

Re: Bug status transitions ~ bug 27908

by Austin English

2011/7/27 <wylda(a)volny.cz>: > > Hi, > > there is bug 27908, which i closed as invalid, because user did not > used latest fixed version. > > > AJ says: If there was a bug then it's FIXED. > > > Based on that, even if the user has a crash in 1.0.1 and opens _now_ > a bug and one day later says "it is FIXED in 1.3.25", then it should > be marked as FIXED. > > Because i noticed before, that this is handled differently, i'm > writing here about above rule, which unify that. > > Regards, > W. In the case of bug 27908, there was no release yet, and I don't think it's unreasonable for a user to report bugs that are in the latest release. Building from git is a time/space consuming pain for most users. If a user reports a bug in a very old release, it's not unreasonable to ask them to try in a newer release before looking at the bug. If the bug was reported in old wine and fixed in newer, well, it technically was fixed, but marking it invalid helps prevent skewing our bug statistics (and may encourage the user to try latest development releases before reporting bugs) :). -- -Austin

July 27, 2011

NtQuerySystemInformation needs a little bit more flesh for SystemProcessorPerformanceInformation

by Paul Vriens

Hi, I was trying out the latest SysInternals Process Explorer and it struck me that the overall CPU % stayed at 0. Adding some values to the sppi structure fixed this but I'm just wondering what values to use: sppi[cpus-1].Reserved1[0].QuadPart = (ULONGLONG)remainder[0] * 10000000 / clk_tck; This Reserved1[0] is the DPC Time but I'm wondering what values from /proc/stat to use here (remainder[0] is I/O wait). We could always make up something of course but being accurate would be nicer. -- Cheers, Paul.

July 27, 2011

Re: gsoc mentor summit

by Stefan Dösinger

On Wednesday 27 July 2011 16:43:36 Owen Rudge wrote: > I'd be interested if there's a space going free. We just get to send 2 > mentors though as I understand it? Yes. I'd be interested as well, that's why I started this thread. I've been there already in 2009, so if anyone else wants to go I'd be happy to yield.

July 27, 2011

Wine and ALSA hw:0, plug:hw, "default" devices, what's the target?

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

Hi, I've never seen a documentation of what Wine expects from the ALSA/OSS/CoreAudio device. - A bare bones "hw:0" device with all its restrictions, e.g. stereo 16bit only? As Wine provides no mixer, this would disallow playing multiple sounds concurrently (bug #NN) on most current sound cards. Some people seem to setup Wine via the registry to use that. - "plug:hw" which can convert 8bit mono to 16bit stereo and provides resampling? (I forgot about the difference with "plughw") - The "dmix" device, which only supports a single rate (typically 48000, see /usr/share/alsa/alsa.conf:defaults.pcm.dmix.rate), accepts only 32bit int(!) samples and restricts #channels like hw:0? This allows to open multiple devices. - The "plug:dmix" device, which chains a resampler and converter with dmix so that it can accept any PCM format? - "pulse", which like "plug:dmix" accepts any PCM format? - "default", which presumably maps to either plug:dmix or pulse so as to accept any PCM format and open multiple devices? It seems obvious Wine needs something as flexible as "pulse" or "plug:dmix" (pure "dmix" won't fit because Wine and apps don't cope well with the 32 bits samples requirement). Does mmdevapi change the equation, happy with dmix instead of plug:dmix as long as both rates are the same? Given that, can't Wine delegate more to the OS? It seems quite stupid to e.g. write a resampler for Wine when ALSA and MacOS' Coreaudio already include one. (On MacOS, couldn't mmdevapi map more to MacOS' audio filter chains?) What's the point of Winealsa's mmdevapi code iterating through ALSA's hw:N devices? IMHO only CoreAudio EXCLUSIVE mode can make use of them. It's a no-no for SHAREDMODE. Or is the plan to be really happy with exclusive access to hw:0 (preventing non Wine apps from doing audio!?!) and implement in Wine's mmdevapi a true mixer as well as a high quality resampler for SHAREDMODE with RATEADJUST and WINMM needs? Who can shed some light? Regards, Jörg Höhle

July 27, 2011