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

Re: ieframe: Moved ie.c tests to ieframe
by Marvin July 28, 2011

July 28, 2011

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=12968 Your paranoid android. === WNT4WSSP6 (32 bit ie) === ie.c:62: Test failed: Could not create InternetExplorer instance: 80040154 ie: unhandled exception c0000005 at 004012F2

2 1

Re: ieframe: Moved ie.c tests to ieframe
by Marvin July 28, 2011

July 28, 2011

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=12967 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

1 0

Bug status transitions ~ bug 27908
by wylda＠volny.cz July 28, 2011

July 28, 2011

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. -- Sháníte letenky na pracovní cestu, dovolenou či jen na výlet? Na http://letenky.volny.cz si zajisté vyberete.

3 2

Re: [PATCH 7/8] wscript: implemented Host_get_Application (resend)
by Marvin July 27, 2011

July 27, 2011

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=12934 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 = "

1 0

Re: [PATCH 6/8] wscript: implemented Host_put_Interactive (resend)
by Marvin July 27, 2011

July 27, 2011

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 = "

1 0

Re: [PATCH 5/8] wscript: implemented Host_get_Interactive (resend)
by Marvin July 27, 2011

July 27, 2011

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 = "

1 0

Re: [PATCH 4/8] wscript: implemented Arguments2_get_length (resend)
by Marvin July 27, 2011

July 27, 2011

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 = "

1 0

Re: [PATCH 3/8] wscript: implemented Arguments2_Count (resend)
by Marvin July 27, 2011

July 27, 2011

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 = "

1 0

Re: [PATCH 1/8] wscript: added arguments.c; implemented Host_get_Arguments (try 2)
by Marvin July 27, 2011

July 27, 2011

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 = "

1 0

Wine and ALSA hw:0, plug:hw, "default" devices, what's the target?
by Joerg-Cyril.Hoehle＠t-systems.com July 27, 2011

July 27, 2011

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

1 0