September 2011 - Wine-Devel

Re: wininet: Ignore the accept types array in HttpOpenRequestA if there are invalid pointers.

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=14577 Your paranoid android. === W7PRO (32 bit http) === http.c:2873: Test failed: HttpSendRequest failed: 12002

Sept. 27, 2011

Re: shell32: Add definitions for the IEnumACString interface.

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=14562 Your paranoid android. === WNT4WSSP6 (32 bit autocomplete) === autocomplete.c:250: Test failed: CoCreateInstance(&CLSID_ACLMulti, NULL, CLSCTX_INPROC, &IID_IEnumString, (LPVOID *)&obj) failed: 80040154 === W2KPROSP4 (32 bit autocomplete) === autocomplete.c:256: Test failed: obj->lpVtbl->QueryInterface(obj, &IID_IEnumACString, (LPVOID*)&unk) failed: 80004002

Sept. 26, 2011

Re: tests: Remove unneeded assert.h includes.

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=14554 Your paranoid android. === WNT4WSSP6 (32 bit autocomplete) === autocomplete.c:249: Test failed: CoCreateInstance(&CLSID_ACLMulti, NULL, CLSCTX_INPROC, &IID_IEnumString, (LPVOID *)&obj) failed: 80040154

Sept. 26, 2011

Re: tests: Remove unneeded assert.h includes.

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=14548 Your paranoid android. === WNT4WSSP6 (32 bit memallocator) === memallocator.c:34: Test failed: Unable to create memory allocator 80040154 === WNT4WSSP6 (32 bit referenceclock) === referenceclock.c:97: Test failed: Unable to create reference clock from system clock 80040154

Sept. 26, 2011

Re: winecfg: Remove driver selection from Audio tab.

by Vitaliy Margolen

On 09/26/2011 09:10 AM, Andrew Eikum wrote: > On Mon, Sep 26, 2011 at 04:50:22PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote: >> I'm not satisfied with the removal of the audio tree from winecfg. >> Beside allowing to switch or disable drivers, one key feature was to >> allow inspecting the devices that winmm found on this system. > > The goal of that patch, like the subject says, was to remove driver > selection. Obviously a side-effect of removing that entire tree was > removing the list of detected devices. I personally don't really see > the use of listing the detected devices, which is why I just removed > the tree wholesale. > > If folks find the device list useful, I wouldn't be at all opposed to > adding it again in some form (obviously it would use MMDevAPI directly > instead of WinMM like the old code... except for MIDI devices, I > guess). I am opposed to adding the driver selection functionality back > in, though. > > Andrew > > Could we please wait another week (until after the wineconf) before doing these whole sale changes? Please leave sound system and related winecfg code as-is. Vitaliy.

Sept. 26, 2011

Re: tests: Remove unneeded assert.h includes.

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=14540 Your paranoid android. === WNT4WSSP6 (32 bit mediadet) === mediadet.c:105: Test failed: CoCreateInstance failed with 80040154 mediadet.c:106: Test failed: pM is NULL mediadet: unhandled exception c0000005 at 00401541 === W2KPROSP4 (32 bit mediadet) === mediadet.c:105: Test failed: CoCreateInstance failed with 80040154 mediadet.c:106: Test failed: pM is NULL mediadet: unhandled exception c0000005 at 00401541 === W2K8SE (32 bit mediadet) === mediadet.c:105: Test failed: CoCreateInstance failed with 80040154 mediadet.c:106: Test failed: pM is NULL mediadet: unhandled exception c0000005 at 00401541

Sept. 26, 2011

Re: msi/tests: Avoid #if 0 to make sure code still compiles.

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=14533 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5998: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

Sept. 26, 2011

Re: [PATCH 6/9 (try2)] winecfg: Replace DirectSound settings with Driver Diagnostics

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > @@ -84,10 +84,11 @@ END > > STRINGTABLE > BEGIN > - IDS_ACCEL_FULL "Full" > - IDS_ACCEL_STANDARD "Standard" > - IDS_ACCEL_BASIC "Basic" > - IDS_ACCEL_EMULATION "Emulation" > + IDS_AUDIO_REG_SETTING "Registry driver setting: %s" > + IDS_AUDIO_REG_DEFAULT "(Default)" > + IDS_AUDIO_REG_DISABLED "(Disabled)" > + IDS_AUDIO_DRIVER "Selected driver: %s" > + IDS_AUDIO_DRIVER_NONE "(None)" Showing the detected driver is a good thing, but we shouldn't need to display the registry setting. The assumption is that users shouldn't have to worry about this. If it's important enough to show in winecfg then it has to be editable in winecfg too. -- Alexandre Julliard julliard(a)winehq.org

Sept. 26, 2011

Re: using (or not) blocking mode with OSS4

by Maarten Lankhorst

Hey Joerg, On 09/26/2011 02:57 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > I've had a glance at the OSS4 mmdevapi logs attached to bug #28056. > Among others, it appears that every renderer iteration takes way too > much time. One possible explanation is that OSS write() takes a lot > of time to return, presumably in an attempt to write more than what's > possible without blocking. > > If you look at AudioRenderClient_ReleaseBuffer and oss_write_data, > you'll see that it writes as much as it has, without querying > GETOSPACE. So it can block. > > open() is called without O_NONBLOCK, so write() will block when given > too much data. > > I don't know yet whether O_NONBLOCK should be used. It's not what the > OSS people recommend. One can argue that NONBLOCK is superfluous when > write is limited via GETOSPACE. > http://manuals.opensound.com/developer/open.html > http://manuals.opensound.com/developer/audio_timing.html > http://manuals.opensound.com/developer/SNDCTL_DSP_NONBLOCK.html > > What do you think about using (or not) blocking mode with OSS? > > W.r.t. ALSA, I'm considering keeping non-blocking mode but switch from > a periodic timer to poll(ALSA_fd, period_timeout). Given a lot of > data, poll would return after the timeout, but when underrun is close, > this should allow to wake up closer to when data is actually needed. > ALSA needs nonblocking because you can never guarantee the pulse plugin works correctly, or one of the other plugins. However for oss it makes sense to query GETOSPACE, so just do that. Nonblocking shouldn't be needed then. ~Maarten

Sept. 26, 2011

re: winmm: waveOutReset returns all buffers.

by Dan Kegel

Fails to apply here. (Requires fuzz, which Alexandre says is verboten.) ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Mon, Sep 26, 2011 at 2:35 AM Subject: Re: 79321: winmm: waveOutReset returns all buffers. To: dank(a)kegel.com, wine-tests-results(a)winehq.org This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/63 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed git Errors: error: patch failed: dlls/winmm/waveform.c:1653 error: dlls/winmm/waveform.c: patch does not apply

Sept. 26, 2011

Re: po: Mark translations with mismatched printf format directives as fuzzy.

by Dan Kegel

On Mon, Sep 26, 2011 at 11:14 AM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Also when Alexandre does "git am" the patch it will fail too. I just asked Alexandre, and he agrees with you that buildbot should reject patches that require fuzz.

Sept. 26, 2011

Re: po: Mark translations with mismatched printf format directives as fuzzy.

by Michael Stefaniuc

On 09/26/2011 06:32 PM, Dan Kegel wrote: > On Mon, Sep 26, 2011 at 2:59 AM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: >> On Mon, Sep 26, 2011 at 8:46 AM, Francois Gouget <fgouget(a)free.fr> wrote: >>> On Sun, 25 Sep 2011, Dan Kegel wrote: >>>> Patch fails to apply here? >>>> >>>> error: patch failed: po/ko.po:11305 >>>> error: po/ko.po: patch does not apply >>> >>> That's strange. The patch attached to the email I received on >>> wine-patches applies fine on a pristine tree here. >> >> Sounds like encoding/charset issues. Dan, is buildbot's the same as >> the file and/or patch? > > Looks like patch and git apply disagree here: > > > $ wget http://source.winehq.org/patches/data/79310 > $ git reset --hard origin > $ patch -p1 < 79310 > patching file po/es.po > patching file po/hu.po > patching file po/ko.po > Hunk #3 succeeded at 11307 with fuzz 2. > patching file po/zh_CN.po > $ git reset --hard origin > HEAD is now at e5ba601 Release 1.3.29. > $ git apply 79310 > error: patch failed: po/ko.po:11305 > error: po/ko.po: patch does not apply > > I guess patch is more willing to fuzz than git apply is; > man git-apply says > -C<n> > Ensure at least <n> lines of surrounding context match > before and after each change. > When fewer lines of surrounding context exist they all must > match. By default no context > is ever ignored. > > I could use git apply -C 1 to match patch's behavior; > what do people think? Don't. There is a very good reason why git apply moved to that default behavior. During my automatic patch generation and testing in the pre-git times I got bitten quite a few times by patch doing the wrong thing with fuzzying to the point of running patch -F 0. Also when Alexandre does "git am" the patch it will fail too. bye michael

Sept. 26, 2011

Re: po: Mark translations with mismatched printf format directives as fuzzy.

by Dan Kegel

On Mon, Sep 26, 2011 at 2:59 AM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > On Mon, Sep 26, 2011 at 8:46 AM, Francois Gouget <fgouget(a)free.fr> wrote: >> On Sun, 25 Sep 2011, Dan Kegel wrote: >>> Patch fails to apply here? >>> >>> error: patch failed: po/ko.po:11305 >>> error: po/ko.po: patch does not apply >> >> That's strange. The patch attached to the email I received on >> wine-patches applies fine on a pristine tree here. > > Sounds like encoding/charset issues. Dan, is buildbot's the same as > the file and/or patch? Looks like patch and git apply disagree here: $ wget http://source.winehq.org/patches/data/79310 $ git reset --hard origin $ patch -p1 < 79310 patching file po/es.po patching file po/hu.po patching file po/ko.po Hunk #3 succeeded at 11307 with fuzz 2. patching file po/zh_CN.po $ git reset --hard origin HEAD is now at e5ba601 Release 1.3.29. $ git apply 79310 error: patch failed: po/ko.po:11305 error: po/ko.po: patch does not apply I guess patch is more willing to fuzz than git apply is; man git-apply says -C<n> Ensure at least <n> lines of surrounding context match before and after each change. When fewer lines of surrounding context exist they all must match. By default no context is ever ignored. I could use git apply -C 1 to match patch's behavior; what do people think? - Dan

Sept. 26, 2011

Re: Before you leave for wineconf...

by Dan Kegel

On Mon, Sep 26, 2011 at 1:20 AM, Francois Gouget <fgouget(a)free.fr> wrote: >> http://kegel.com/wine/loop-fail.sh.txt >> overnight on the hardware you plan to bring, and >> email me the results? It creates a log file >> loop-fails.log which lists each test failure and >> how many loops it took to get there. > > If the goal is to run the loop till the first crash then that works > fine. But if the goal is to get the maximum amount of data on failures > one should first disable the debugger crash dialog. OK, that script now disables the debugger crash dialog. (It also adds another couple tests that were failing frequently on Austin's box.) BTW, here are my own results from my e8400 system, left running for an hour: $ awk '/FAIL/ {print $4}' < loop-fails.log | sort | uniq -c | sort -nr 31 dlls/gdi32/tests/bitmap.ok 31 dlls/dsound/tests/dsound.ok 31 dlls/dsound/tests/dsound8.ok 31 dlls/dsound/tests/ds3d8.ok 30 dlls/dsound/tests/ds3d.ok 23 dlls/wininet/tests/urlcache.ok 3 dlls/winmm/tests/wave.ok 1 dlls/user32/tests/win.ok

Sept. 26, 2011

Re: [1/2] kernel32: Add a test for VirtualProtect.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > +static void test_VirtualProtect(void) > +{ > + static const struct test_data > + { > + DWORD prot_set, prot_get; > + } td[] = > + { > + { PAGE_NOACCESS, PAGE_NOACCESS }, > + { PAGE_READONLY, PAGE_READONLY }, > + { PAGE_READWRITE, PAGE_READWRITE }, > + { PAGE_WRITECOPY, 0 }, > + { PAGE_EXECUTE, PAGE_EXECUTE }, > + { PAGE_EXECUTE_READ, PAGE_EXECUTE_READ }, > + { PAGE_EXECUTE_READWRITE, PAGE_EXECUTE_READWRITE }, > + { PAGE_EXECUTE_WRITECOPY, 0 } You should also test various invalid combinations. -- Alexandre Julliard julliard(a)winehq.org

Sept. 26, 2011

Re: [PATCH 7/9] dsound: Reimplement rendering devices on mmdevapi

by Andrew Eikum

On Mon, Sep 26, 2011 at 05:05:28PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > I agree that dsound -> winmm -> mmdevapi is an abomination. > > However, this all goes too fast for me. > We don't have a fool-proof mmdevapi yet (neither ALSA, nor OSS, nor CoreAudio). > We don't have a bug-free winmm->mmdevapi yet. This is a valid worry/complaint. The reason I wanted to get all of the 'big stuff' (mmdevapi, winmm, dsound rewrites) out of the way quickly was so I can start focusing on the bugs. I have been largely ignoring dsound bugs, since I knew dsound was going to be reworked anyway. I certainly had no interest in fixing bugs with dsound set to Full hardware acceleration, which is the default, since almost all of that code was going to disappear. With the dsound->mmdevapi conversion work done, I think it's worth spending time investigating and fixing the dsound bugs. I'd much rather spend time on the bugs once we've got the "permanent" code in place, than messing around with code that's going to be significantly reworked anyway. I know it's frustrating in the meanwhile, but I really feel that it's not in as bad a situation as you think. At least I think it's much more pleasant to debug the new code than the old :) > I believe users are happy to still have dsound HW acceleration in ALSA > since 1.3.25 to compare it with the new HW emulation behaviour via mmdevapi. dsound hwaccel mode really puts a wrench in getting good quality bug reports. Users don't understand all of the different audio options and often don't include that information in bugs. Killing hwaccel is something I want to do absolutely as soon as possible. Getting a handful of new dsound->winmm->mmdevapi->driver bugs hardly seems worth it when we're going to convert to the new chain anyway, so I thought do it all at once. Andrew

Sept. 26, 2011

Re: winecfg: Remove driver selection from Audio tab.

by Andrew Eikum

On Mon, Sep 26, 2011 at 04:50:22PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > I'm not satisfied with the removal of the audio tree from winecfg. > Beside allowing to switch or disable drivers, one key feature was to > allow inspecting the devices that winmm found on this system. The goal of that patch, like the subject says, was to remove driver selection. Obviously a side-effect of removing that entire tree was removing the list of detected devices. I personally don't really see the use of listing the detected devices, which is why I just removed the tree wholesale. If folks find the device list useful, I wouldn't be at all opposed to adding it again in some form (obviously it would use MMDevAPI directly instead of WinMM like the old code... except for MIDI devices, I guess). I am opposed to adding the driver selection functionality back in, though. Andrew

Sept. 26, 2011

[PATCH 7/9] dsound: Reimplement rendering devices on mmdevapi

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

Hi, I agree that dsound -> winmm -> mmdevapi is an abomination. However, this all goes too fast for me. We don't have a fool-proof mmdevapi yet (neither ALSA, nor OSS, nor CoreAudio). We don't have a bug-free winmm->mmdevapi yet. Since June, I've done nothing than analyse code and fix bugs to help The Wine project in my free time. My wife has already signaled that she's not pleased. I've installed zero SW for the children since that time. Well, my choice, but I'm growing tired. It appears that I've a biased view on the current audio situation because I see all the bugs. The user experience does not seem that bad, from what a few users told me. Currently, having dsound -> winmm -> mmdevapi may not be satisfying, but it helps to find hairy bugs fast (more apps use dsound than winmm). After the initial winmm transition, I did not even look at dsound or winmm bugs because there's no point in doing so when they depend on a mmdevapi which is not yet robust enough. So I concentrated on mmdevapi. It's only recently that I've started to look at winmm now that I believe to know well most remaining ALSA and CoreAudio mmdevapi bugs. I'm solely starting on OSS bugs. I believe users are happy to still have dsound HW acceleration in ALSA since 1.3.25 to compare it with the new HW emulation behaviour via mmdevapi. Is a 1.4 release target this year the reason for pushing out code fast? Regards, Jörg Höhle

Sept. 26, 2011

winecfg: Remove driver selection from Audio tab.

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

Hi, I'm not satisfied with the removal of the audio tree from winecfg. Beside allowing to switch or disable drivers, one key feature was to allow inspecting the devices that winmm found on this system. For instance, I've not yet had time to report a bug that since wine-1.3.25, one such entry shows an empty name IIRC. It allowed users to easily check whether e.g. Timidity was recognized or whether "MIDI through" was the only output. It allowed users to easily tell whether their 5:1 sound card was recognized beside the default device. Bugzilla shows 350 entries about winecfg & audio. It had a use. What are users supposed to do now? Regards, Jörg Höhle

Sept. 26, 2011

Warning report for wine-1.3.29-5-gf04f0b3

by Jerome Leclanche

Operating System Linux azura 3.0.0-10-generic #16-Ubuntu SMP Fri Sep 2 18:32:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Configuration (32-bit) '--prefix=/usr' '--libdir=/usr/lib32' '--enable-tests' '--disable-win64' '--with-wine64=/home/adys/src/wine/build64' '--with-alsa' '--with-freetype' '--without-gstreamer' '--with-jpeg' '--with-ldap' '--with-openal' '--with-opengl' '--with-openssl' '--with-png' '--with-x' '--with-xinerama' '--with-xinput2' '--with-xml' '--with-xrandr' '--without-capi' '--without-cms' '--without-cups' '--without-curses' '--without-fontconfig' '--without-gettextpo' '--without-gnutls' '--without-gphoto' '--without-gsm' '--without-hal' '--without-mpg123' '--without-opencl' '--without-oss' '--without-sane' '--without-tiff' '--without-v4l' '--without-xslt' '--without-xxf86vm' 'CC=ccache gcc -msse4 -O3 -Wall' Configuration (64-bit) '--prefix=/usr' '--libdir=/usr/lib' '--enable-tests' '--enable-win64' '--with-alsa' '--with-freetype' '--without-gstreamer' '--with-jpeg' '--with-ldap' '--with-openal' '--with-opengl' '--with-openssl' '--with-png' '--with-x' '--with-xinerama' '--with-xinput2' '--with-xml' '--with-xrandr' '--without-capi' '--without-cms' '--without-cups' '--without-curses' '--without-fontconfig' '--without-gettextpo' '--without-gnutls' '--without-gphoto' '--without-gsm' '--without-hal' '--without-mpg123' '--without-opencl' '--without-oss' '--without-sane' '--without-tiff' '--without-v4l' '--without-xslt' '--without-xxf86vm' 'CC=ccache gcc -msse4 -O3 -Wall' -- J. Leclanche

Sept. 26, 2011

using (or not) blocking mode with OSS4

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

Hi, I've had a glance at the OSS4 mmdevapi logs attached to bug #28056. Among others, it appears that every renderer iteration takes way too much time. One possible explanation is that OSS write() takes a lot of time to return, presumably in an attempt to write more than what's possible without blocking. If you look at AudioRenderClient_ReleaseBuffer and oss_write_data, you'll see that it writes as much as it has, without querying GETOSPACE. So it can block. open() is called without O_NONBLOCK, so write() will block when given too much data. I don't know yet whether O_NONBLOCK should be used. It's not what the OSS people recommend. One can argue that NONBLOCK is superfluous when write is limited via GETOSPACE. http://manuals.opensound.com/developer/open.html http://manuals.opensound.com/developer/audio_timing.html http://manuals.opensound.com/developer/SNDCTL_DSP_NONBLOCK.html What do you think about using (or not) blocking mode with OSS? W.r.t. ALSA, I'm considering keeping non-blocking mode but switch from a periodic timer to poll(ALSA_fd, period_timeout). Given a lot of data, poll would return after the timeout, but when underrun is close, this should allow to wake up closer to when data is actually needed. Regards, Jörg Höhle

Sept. 26, 2011

Re: Quick Question

by Ben Peddell

On 26/09/2011 3:07 PM, Peter Wilson wrote: > Hi, > > Quick question, might be silly, but is there a version of Wine that can be installed on windows or linux to create apps for Mac? > > I just want to keep my mac clean and try run things in a dev environment, and apple are always so polite to make visualization a pain… > > Thank you very much for you help, > > Kind Regards, > > Peter Wilson > Wine is an implementation of the Windows APIs that will run on Linux and Mac OS X (and others). It sounds like you are asking for a binary-compatible implementation of the Carbon / Cocoa APIs that will run on Linux or Windows, as well as a Windows or Linux hosted development environment targeted to the Carbon / Cocoa APIs. If you are the one developing the application, why not use one of the cross-platform graphical libraries such as SDL, GTK+, wxWidgets, etc. If the application uses 3D graphics, many of those cross-platform graphical libraries also have support for OpenGL. If you don't want to have to re-compile between your host platform and your target platform, then you'd have to use something like Java or Mono to build a platform-independent binary, use Python or similar, or install Wine on the Mac and create a Windows binary. -- Ben Peddell IT Support Bowen, Collinsville, Proserpine and Home Hill Catholic schools http://klightspeed.killerwolves.net/

Sept. 26, 2011

Re: po: Mark translations with mismatched printf format directives as fuzzy.

by Jerome Leclanche

Sounds like encoding/charset issues. Dan, is buildbot's the same as the file and/or patch? On Mon, Sep 26, 2011 at 8:46 AM, Francois Gouget <fgouget(a)free.fr> wrote: > On Sun, 25 Sep 2011, Dan Kegel wrote: > >> Patch fails to apply here? >> >> error: patch failed: po/ko.po:11305 >> error: po/ko.po: patch does not apply > > That's strange. The patch attached to the email I received on > wine-patches applies fine on a pristine tree here. > > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Linux: the choice of a GNU generation > > >

Sept. 26, 2011

Re: Before you leave for wineconf...

by Francois Gouget

On Fri, 23 Sep 2011, Dan Kegel wrote: > ... could you run > http://kegel.com/wine/loop-fail.sh.txt > overnight on the hardware you plan to bring, and > email me the results? It creates a log file > loop-fails.log which lists each test failure and > how many loops it took to get there. If the goal is to run the loop till the first crash then that works fine. But if the goal is to get the maximum amount of data on failures one should first disable the debugger crash dialog. ./wine "./programs/regedit/regedit.exe.so" - <<__EOF__ [HKEY_CURRENT_USER\Software\Wine\WineDbg] "ShowCrashDialog"=dword:00000000 __EOF__ -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

Sept. 26, 2011

re: po: Mark translations with mismatched printf format directives as fuzzy.

by Francois Gouget

On Sun, 25 Sep 2011, Dan Kegel wrote: > Patch fails to apply here? > > error: patch failed: po/ko.po:11305 > error: po/ko.po: patch does not apply That's strange. The patch attached to the email I received on wine-patches applies fine on a pristine tree here. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: the choice of a GNU generation

Sept. 26, 2011