September 2009 - Wine-devel

Testcase for IStorage_CreateStorage
by Markus Stockhausen 16 Sep '09

16 Sep '09

Hi, as I'm still working on a resolution to bug #9575 I have digged into several directions. My current opinion is that IStorage_CreateStorage for some unkown reason increments the reference pointer of the associated IStorage object. In native Windows this is not the case. My 37th try in writing a Wine testcase resulted in the following code that hopefully shows the difference between the two environments. I put it somewhere in the storage32 tests to get it running. No warranty for side effects. static const WCHAR yyy[] = { 'x','.','t','x','t',0 }; r = StgOpenStorage( yyy, NULL, STGM_TRANSACTED | STGM_SHARE_EXCLUSIVE | STGM_READWRITE , NULL, 0, &stg); ok(r==S_OK, "StgCreateStorage failed\n"); if(stg) { static const WCHAR xxx[] = { 'D','a','t','a','S','p','a','c','e','I','n','f','o',0 }; IStorage_CreateStorage(stg,xxx,STGM_READWRITE | STGM_SHARE_EXCLUSIVE,0,0,&stg2); if (stg2) { r = IStorage_AddRef(stg); ok(r == 2, "WINE ERROR: refcount should be 2\n"); IStorage_Release(stg2); while ( r ) r=IStorage_Release(stg); } else { ok( 1 == 2, "IStorage::CreateStorage failed\n"); IStorage_Release(stg); } } If I got everything in the right place this test should fail on Wine wheres it will be ok in Windows. Before doing further research I hope someone of the experts can check if the test really reveals the source of the above mentioned bug. Thanks in advance.

1 0

now OSS driver emulation -- and other drivers too -- works as well as OSS HW mode; block size error gone?
by Joerg-Cyril.Hoehle＠t-systems.com 16 Sep '09

16 Sep '09

Hi, if your app worked well in OSS HW driver mode but not in emulation mode, the following patch may help you. For me, it fixed the following: - wrong playback speed in some apps (bug #19901); - spurious errors about block size: err:dsound:DSOUND_MixInBuffer length not a multiple of block size, len = 1579, block size = 2 - an assertion failure and crash (bug #12349): mixer.c:489: DSOUND_MixInBuffer: Assertion `dsb->buf_mixpos + len <= dsb->tmp_buffer_len' failed. As the MacOS CoreAudio driver produces sound effects much like OSS emulation, a similar fix to wineCoreAudio.drv will certainly cure sound on the Mac, lifting some apps' rating from garbage to gold! diff --git a/dlls/wineoss.drv/audio.c b/dlls/wineoss.drv/audio.c index ca79cd5..9ef0d5b 100644 --- a/dlls/wineoss.drv/audio.c +++ b/dlls/wineoss.drv/audio.c @@ -2071,6 +2071,13 @@ static DWORD wodOpen(WORD wDevID, LPWAVEOPENDESC lpDesc, DWORD dwFlags) wwo->waveFormat.Format.nSamplesPerSec) / wwo->waveFormat.Format.nChannels; } + if (wwo->waveFormat.Format.nBlockAlign != wwo->waveFormat.Format.nChannels * + wwo->waveFormat.Format.wBitsPerSample / 8) { + WARN("Fixing BlockAlign\n"); + wwo->waveFormat.Format.nBlockAlign = wwo->waveFormat.Format.nChannels * + wwo->waveFormat.Format.wBitsPerSample / 8; + lpDesc->lpFormat->nBlockAlign=wwo->waveFormat.Format.nBlockAlign; /* see DirectSoundDevice_Create */ + } /* Read output space info for future reference */ if (ioctl(wwo->ossdev.fd, SNDCTL_DSP_GETOSPACE, &info) < 0) { ERR("ioctl(%s, SNDCTL_DSP_GETOSPACE) failed (%s)\n", wwo->ossdev.dev_name, strerror(errno)); The problem is that Wine depends on invariants about BlockAlign and AvgBytesPerSec but does not enforce them when presented incorrect data. MSDN says http://msdn.microsoft.com/en-us/library/bb669161(VS.85).aspx "If wFormatTag is WAVE_FORMAT_PCM or WAVE_FORMAT_EXTENSIBLE, nBlockAlign must be equal to the product of nChannels and wBitsPerSample divided by 8 (bits per byte). If wFormatTag is WAVE_FORMAT_PCM, nAvgBytesPerSec should be equal to the product of nSamplesPerSec and nBlockAlign." In the source base up to now, Wine only corrects the format in the OSS hardware mode. That's why OSS HW works well. It's too early to submit this as a patch as there are a few open issues: - Does the bogus data originate from the app or is some other function in Wine returning this data? A trace snippet from bug #19901 shows inconsistent data in the following call to SetFormat following device creation: PrimaryBufferImpl_Create (formattag=0x0001,chans=2,samplerate=44100,bytespersec=176400,blockalign=4,bitspersamp=16,cbSize=0) DSOUND_PrimarySetFormat (formattag=0x0001,chans=1,samplerate=22050,bytespersec=88200,blockalign=4,bitspersamp=16,cbSize=0) - Is there some central place in dsound for enforcing the invariant instead of identical code in the half dozen OSS/ALSA/CoreAudio/Jack etc. drivers? - Is the modification of the WAVEOPENDESC structure allowed, as it seems to be a user-supplied structure, which should be handled read-only? - Should the sound driver refuse to open when submitted such incorrect data? Possibly not. MSDN says about SetFormat http://msdn.microsoft.com/en-us/library/bb206041(VS.85).aspx "The method succeeds even if the hardware does not support the requested format; DirectSound sets the buffer to the closest supported format. To determine whether this has happened, an application can call the GetFormat ..." Thus, DS may set a format different from what was supplied. Presumably, BlockAlign and AvgBytesPerSec play a minor role, as they can be derived from the other values. Experimentally, I had wineoss.drv/audio.c:supportedformat() refuse inconsistent formats. Wine nevertheless played the app's sound at bogus speed after scanning all wineacm/mp3/xyz drivers (which it would not do otherwise), taking an execution path I've not yet analysed. - How does MS-Windows behave in the presence of bad data? Additional tests are needed. - I've not yet fixed the ALSA driver, but I expect similar improvements, at least in the emulation case, because the sound errors are the same in OSS and ALSA emulation modes. This is exciting news about progress in Wine sound issues! Bugzilla has errors about block size as old as 2005 still open. Regards, Jörg Höhle

2 4

Down to an average of 1% failures on my Windows boxes
by Paul Vriens 16 Sep '09

16 Sep '09

Hi, Just wanting to let you know that I'm down to 1% average failures on my Windows boxes (W95/W98/NT4/W2K/XP/W2K3/Vista). Short list: Sep-2009 : 1% Jun-2009 : 2% May-2009 : 3% Mar-2009 : 4% Feb-2009 : 5% So I doubt we get to zero before WineConf ;) -- Cheers, Paul.

1 0

CertGetPublicKeyLength() test failures on Win7
by Greg Geldorp 15 Sep '09

15 Sep '09

Hi Juan, I see 3 test failures related to CertGetPublicKeyLength() on Win7, crypt32/tests/cert.c lines 3146/3160/3165. All 3 failures are the same, CertGetPublicKeyLength() returns 0 with last error 0x80090004 (NTE_BAD_LEN). After looking at it for a while, I'm inclined to change the condition to ok(ret == 56 || (ok == 0 && GetLastError() == NTE_BAD_LEN), ...). Do you agree that's the correct fix or do I need to dig deeper? Thanks, Ge.

2 4

Wine at Ohloh
by Saulius Krasuckas 15 Sep '09

15 Sep '09

FYI, http://www.ohloh.net/p/wine/analyses/latest I wonder how do they find 27k lines of C++ code in Wine tree...

4 4

Re: [PATCH 2/2] dpwsockx: Implementation of Open callback
by Vitaliy Margolen 15 Sep '09

15 Sep '09

Ismael Barros wrote: > --- > +static DWORD WINAPI udp_listener_thread( LPVOID lpParameter ) > +{ > + for ( ;; ) > + { ..... > + } > +} You do not have exit from the loop. > + /* Launch thread */ > + listener->handle = CreateThread( NULL, 0, udp_listener_thread, > + listener, 0, NULL ); I haven't found the place where you closing this handle. > + /* Launch thread */ > + listener->handle = CreateThread( NULL, 0, > + ( is_tcp > + ? tcp_listener_thread > + : udp_listener_thread ), > + listener, 0, NULL ); Same here. Vitaliy.

3 7

re: [3/4] msi: GetDriveType and GetVolumeInformation require a path terminated by a slash.
by Dan Kegel 15 Sep '09

15 Sep '09

Don't changes like this need corresponding conformance tests? Likewise with "[4/4] msi: Don't append the cabinet file name in find_published_source."

2 1

How I create wine app launcher icons on the Mac
by Joerg-Cyril.Hoehle＠t-systems.com 15 Sep '09

15 Sep '09

Hi, On Linux, I have been using .desktop files that freedesktop defines to keep a directory full of icons. They all launch Wine applications. Often enough, these desktop files are initially create by Wine in ~/.local/share/applications/wine/..., along with the icon files in ~/.local/share/icons/. Here's how I now have app launcher icons on the Mac: sips -i ~/.local/share/icons/foo.png --out foo.png # sips -i converts and *additionaly* adds icon resource to file # Alas, sips does not understand .xpm cat sample.command > foo.png # > overwrites contents but keeps resource fork mv foo.png ~/Desktop/foo.command # .command is the finder's suffix for executable shell scripts chmod a+x foo.command sample.command contains: #!/bin/sh cd /User/me/xyz && WINEDEBUG=-gsm WINEPREFIX=$HOME/.wine exec wine xyz.exe Afterwards you edit foo.command and change the directory, environment variables and executable names to meet your needs. Be careful to use an editor that keeps the resource fork. "Opening" this icon will launch a Terminal where all logs will go. Optionally you may use Cmd-I(nformation) to disable the display of the .command suffix in the finder (unless forced globally). Wine's X11 window opens above the Terminal window. I wonder whether this functionality could be somehow integrated into the git (winemenubuilder?), or whether developers believe this should be left to "surrounding" projects like Darwine. What do you think? Jörg Höhle PS: You can wrap up the whole thing into a single shell script using the cat <<EOF syntax.

2 3

Re: [1/2] comctl32: Implement highlighting (marquee) selection support in listview
by Nikolay Sivov 14 Sep '09

14 Sep '09

Owen Rudge wrote: > These patches add support for selecting multiple items in a > multi-selection listview using the mouse (by dragging and highlighting). > > --- > dlls/comctl32/listview.c | 172 > ++++++++++++++++++++++++++++++++++++++++++---- > 1 files changed, 157 insertions(+), 15 deletions(-) Hi, Owen. Some comments. --- @@ -201,6 +201,7 @@ typedef struct tagITEM_INFO LPARAM lParam; INT iIndent; ITEM_ID *id; + UINT orig_state; /* state before highlighting operation begins */ } ITEM_INFO; --- Why do you need this restoring code? If you're starting selection box with some items selected they should be deselected if not Shift pressed and leaved untouched if Shift used. I don't see a reason to restore it - when you want to toggle selected state moving rectangle with Ctrl pressed you could just: LISTVIEW_GetItemState() and place inverted state with following LISTVIEW_SetItemState(). Also such large cycles shouldn't be used if you could manage not to use them. Currently we're not doing right sometimes with ownerdata lists which leads to huge response times (see http://bugs.winehq.org/show_bug.cgi?id=14303) Anyway this part: --- + /* Take a snapshot of all the item states */ + for (i = 0; i < infoPtr->nItemCount; i++) + { + hdpaSubItems = DPA_GetPtr(infoPtr->hdpaItems, i); + lpItem = DPA_GetPtr(hdpaSubItems, 0); + + if (lpItem) + lpItem->orig_state = lpItem->state; + } --- is wrong. You can't do it that way cause selected state could also be cached at parent side with corresponding callback bit set (look at LISTVIEW_GetItemT()). P.S. No need to split in two patches here, fist is useless if we can't see rectangle.

2 2

Re: [PATCH 1/1] winecoreaudio: make supported format test more restrictive
by Ken Thomases 14 Sep '09

14 Sep '09

On Sep 14, 2009, at 6:21 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> <Joerg-Cyril.Hoehle(a)t-systems.com > wrote: > supportedformat() has been in OSS' audio.c since 2004, so the > coreaudio driver was forked even before that time?!? Well, the CoreAudio driver was based on the ALSA driver. So, if ALSA was copied from the OSS driver before that change was made, then effectively, yes, the CoreAudio driver was forked before that time. -Ken

1 0