November 2007 - Wine-Devel - list.winehq.org

RE: Bugzilla rights

by EA Durbin

----------------------------------------> Date: Tue, 6 Nov 2007 12:45:39 -0700> From: wine-devel(a)kievinfo.com> To: wine-devel(a)winehq.org> Subject: Bugzilla rights>> Bugzilla admin, please disallow people to add/remove e-mail addresses> to/from bugs unless they've been given that right. Or at least have rights> to modify any aspect of the bug.>> Thanks,> Vitaliy.>> Doing this would break the ability of users to add the author of patches that cause a regression as outlined in the wiki. http://wiki.winehq.org/RegressionTesting _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

Nov. 6, 2007

Re: RICHED20: fix test failure in test_WM_PASTE

by Alex Villacís Lasso

Alex Villacís Lasso escribió: > At last! I finally found the way to make native riched20 actually obey > keystrokes involving Ctrl and some other key. It seems that native riched20 > checks the actual keyboard state during WM_KEYDOWN processing, and won't > process keystrokes if the keyboard state does not match the messages being > sent. However, with keybd_event(), native riched20 can be fooled into > accepting > simulated keystrokes. > > Changelog: > * Native riched20 won't obey simple WM_CHAR or WM_KEYDOWN/WM_KEYUP messages > when processing Ctrl-Key keystrokes. Use keybd_event() instead. Fixes one > test failure in Win98 and WinXP-SP2. > * Add more through tests to test_WM_PASTE, to check that text is actually > being modified in intermediate steps. Fixes false test success in Win98 and > WinXP-SP2. Additional tests pass under Win98, WinXP-SP2 and Wine. > ------------------------------------------------------------------------ > Was there something wrong with this patch? Two other patches of mine for riched20 have been committed, but not this one. As it currently stands, it removes the last test failure and also fixes a false test success in WinXP-SP2. -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

Nov. 6, 2007

Bugzilla rights

by Vitaliy Margolen

Bugzilla admin, please disallow people to add/remove e-mail addresses to/from bugs unless they've been given that right. Or at least have rights to modify any aspect of the bug. Thanks, Vitaliy.

Nov. 6, 2007

Develop .h for Wine by looking Microsoft Platform SDK

by Pau Garcia i Quiles

Hello, How legal (if at all) would be to develop a header file by looking reading the corresponding header file from the Microsoft Platform SDK and adapting it to gcc (removing MSVC stuff, etc)? I'm interested in supporting annotations[*] and before I start deducting everything from MSDN documentation, I'd like to know if there is a fast track. [*] More information: http://msdn2.microsoft.com/en-us/library/aa383701.aspx http://msdn2.microsoft.com/en-us/library/ms235402(VS.80).aspx Thank you. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

Nov. 6, 2007

valgrind results 20071106

by Dan Kegel

http://kegel.com/wine/valgrind/20071106/ Most obvious change since yesterday is Juan fixed the warnings in setupapi, so that DLL is now clean by this test.

Nov. 6, 2007

Re: xrun handling in winealsa.drv

by Maarten Lankhorst

Hello Timofei, Timofei V. Bondarenko schreef: > I've noticed the winealsa does not handle alsa XRUNs. > In the case of XRUN application hangs. > I'm aware of the xrun problems in alsa at least the accelerated parts (dsoutput/dscapture), it's been on my todo list for a while but I've been busy lately. The problems with the accelerated parts are not the underruns themselves. They are handled correctly in the places where it matters. The problem is how the underruns are handled in the directsound software mixer. I haven't taken a look yet at how underruns are handled for the not-accelerated system, but I believe that the chance of a underrun there is already very low because buffers there usually have a latency of at least 300ms. Regards, Maarten.

Nov. 6, 2007

Monday's valgrind results - ten tests fixed!

by Dan Kegel

Yesterday's git seems to have fixed all the valgrind warnings in ten tests: cabinet/extract cabinet/fdi crypt32/sip d3d8/device dsound/dsound8 mscms/profile mshtml/dom mshtml/htmldoc netapi32/access shdocvw/webbrowser Results are online at http://kegel.com/wine/valgrind/20071105/ (Sorry, I used an old suppressions file, so this has a lot of leak records in it that should have been suppressed. I'll sort that for today's git results.)

Nov. 6, 2007

xrun handling in winealsa.drv

by Timofei V. Bondarenko

Hi. I've noticed the winealsa does not handle alsa XRUNs. In the case of XRUN application hangs. That's happened because return value of snd_pcm_avail_update() is not checked. For example: wavein.c 175 DWORD bytes; 180 /* read all the fragments accumulated so far */ 181 frames = snd_pcm_avail_update(wwi->pcm); 182 bytes = snd_pcm_frames_to_bytes(wwi->pcm, frames); waveout.c 476 DWORD availInQ; 479 availInQ = snd_pcm_avail_update(wwo->pcm); 482 if (availInQ > 0) { The snd_pcm_avail_update() returns a _signed_ type and it really does return negative number -EPIPE in the case of XRUN. More over, any return value of less than period_size may indicate XRUN state too. The snd_pcm_state() may help then. Th dsoutput.c and dscapture.c do exactly the same wrong thigs. BTW, using DWORD type causes problems. Following fragment is from wavein.c too: 177 DWORD read; 181 frames = snd_pcm_avail_update(wwi->pcm); 182 bytes = snd_pcm_frames_to_bytes(wwi->pcm, frames); 193 read = wwi->read(wwi->pcm, lpWaveHdr->lpData + 194 bytesRead = snd_pcm_frames_to_bytes(wwi->pcm, 197 if (bytesRead != (DWORD) -1) This is obviously will not work as expected. I hope someone will fix these issues :) Regards, Tim.

Nov. 6, 2007

Re: [1/2] explorer: Store current display mode in the registry on startup

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > Changelog: > [1/2] explorer: Store current display mode in the registry on startup. You should either do that only in the case of using the X11 root window, or you need to use a different registry key for each virtual desktop instance. -- Alexandre Julliard julliard(a)winehq.org

Nov. 6, 2007

Re: [SPAM] Re: USER32: win16 applications should not see long filenames returned from dialog control (try 2)

by Alexandre Julliard

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > Sorry, but I have to object. According to the documentation in MSDN, > DlgDirSelectExA returns nonzero when the current selection is a > directory name, and zero when it is not. However, plain filenames do not > qualify as directory names, so DlgDirSelectExA won't return nonzero on > them either. I checked on wine's implementation just to be sure. So > checking ret will not tell apart a case of failure from a case of a > plain filename being returned. That is why I need to zero out the last > error and check against it after return. That still won't work, because our implementation doesn't set last error on failure. Maybe it should, but that will require some test cases. -- Alexandre Julliard julliard(a)winehq.org

Nov. 6, 2007