December 2002 - Wine-Devel - list.winehq.org

Re: Make RECT identical to RECTL, fix compile warnings (resending)

by Dan Kegel

Dimitrie O. Paun wrote: > On December 27, 2002 01:29 pm, Dan Kegel wrote: > >>I think this patch touches every single TRACE >>statement that prints out a RECT. Many different >>formats are used... might be nice to standardize them >>sometime. ... > > Now that you've identified all these places, it seems to me > the perfect oportunity to standardise them. At the very least, > we should convert them all to a common format (say (x0,y0)-(x1,y1), > or anything you fancy) so we can more easily grep/sed for them > later. But I'd certainly prefer the debugrect() approach, provided > Alexandre accepts it. Note that some of these print out the corners, but others output one corner plus width and height. Will anyond mind terribly if we always just print out the corners? I think I'll start off by switching to the common format you suggest, and using just one macro to deal with arguments. e.g. RECT stuff[20]; ... TRACE("the 6th rect is (%ld,%ld)-(%ld,%ld)\n", RECT_LTRB(stuff+5)); That will make it trivial to switch to the debugrect() approach later, which as someone pointed out involves a bit more infrastructure work (because of the buffer it has to allocate). All we'll need is find . -name *.c | xargs perl -p -i.bak -e 's/(%ld,%ld)-(%ld,%ld)/%s/g' -e 's/RECT_LTRB/debugrect/g' Ok, off to do a little patch munging... I can resubmit the patch this weekend if I'm lucky. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Dec. 28, 2002

WinXP conformance test update

by David Miller

I noticed two tests were still missing information. Here are the results of those tests. C:\winetests>kernel32_test.exe file file.c:633:Current offset = 0015 file.c:658:Current offset = 0015 file: 487239 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe generated generated: 609 tests executed, 0 marked as todo, 0 failures.

Dec. 28, 2002

Re: Changing FS type reported by Wine

by Sylvain Petreolle

Why should we obey to all windows limitations ? Remember, Wine Is Not an Emulator. Other point, you can read&write on NTFS volumes using several tools as Ntfsdos from http://www.sysinternals.com > Surely from Windows p-o-v _no_ other return values should be > legitimate. > Can windows natively read any other types? I don't think so. > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/bas… > > Since it is hardcoded, I don't know how you would "set up new drive > > > letters for the specific file systems you needed." An option in > > ~/.wine/config, on the otherhand, would make this easy. > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Dec. 28, 2002

Re: Documentation work -task list -man pages

by Dimitrie O. Paun

On December 28, 2002 02:25 am, Tom Wickline wrote: > OK....... Fine with me can we just break this down to smaller task ? Of course, we must break it down further. It's just that I did not know how to do it, and I was hoping someone more familiar with the documentation will do it instead. -- Dimi.

Dec. 28, 2002

Re: DirectSound and i810 soundcards

by Ove Kaaven

On Sat, 28 Dec 2002, Francois Gouget wrote: > When DSound initializes it create a primary sound buffer and invokes > winmm to actually get access to a sound device. The default format of > the primary buffer is 22050x16x2 (i.e. 22050Hz, 16 bit sound, stereo). > This means the device it's going to get will be handled by msacm.drv > which will be responsible for performing the conversions on the fly. > > However during the primary buffer creation DSDB_MapPrimary gets invoked > in wineoss and does an mmap of the hardware sound buffer. > > So when we then play sound in a secondary sound buffer, this sound gets > mixed into the primary buffer, but because of the mmap this then goes > straight to the sound card with no further conversion. So you end up > with a chipmunk sound effect since you play a 22050x16x2 sound at > 48000x16x2. > > I will try to make more tests to confirm this but does it seem to make > sense? Should I look in some other direction? Any suggestion about a fix? I've been meaning to submit the winex wineoss modifications, but haven't got around to it yet, and it might be somewhat complicated by all the changes around it lately. But this particular issue doesn't take a big patch. Basically the 'true' sample rate should be propagated back to dsound, so that it knows that the primary buffer is 48kHz and can resample secondary buffers accordingly. No changes is needed to dsound for this, wineoss's wodOpen just need to modify its waveformat input parameter if the WAVE_DIRECTSOUND flag is present, then dsound will happily convert secondary buffers to that sample rate when mixing them into the primary buffer. (Primary buffers are different, but apps that writes directly into the primary buffer are few, and they should use GetFormat and resample on their own.)

Dec. 28, 2002

Regression in msvideo patch

by Stephen Mollett

Hi, [Following on from a thread on wine-users] I've had some problems recently with running the VirtualDub video post-processing package on Wine. It used to work, but then stopped working (it no longer displays the frame previews when seeking in a video file) recently. I've done a regression test and narrowed the problem down to the patch described in: http://www.winehq.com/hypermail/wine-cvs/2002/11/0187.html Before this patch (2002-11-20 13:47:00 CST), frame preview works normally in VirtualDub. Afterwards, vdub crashes when seeking. Later cvs versions don't crash but don't display frames either. The console output from Wine includes: fixme:msvideo:DrawDibRealize (0x1, 0x8f4, 0), stub just once before a load of messages similar to: fixme:psapi:EnumProcessModules (hProcess=0xffffffff, 0x425cf000, 4096, 0x405c0038) fixme:psapi:GetModuleBaseNameA (hProcess=0xffffffff, hModule=0x400000, "", 65212): stub fixme:psapi:GetModuleBaseNameA (hProcess=0xffffffff, hModule=0x425e0000, "", 65212): stub fixme:psapi:GetModuleBaseNameA (hProcess=0xffffffff, hModule=0x78000000, "", 65212): stub ... when a crash occurs; the later non-crashing versions just display loads of messages similar to the first one about DrawDibRealize. If you like, I can try to track down when the crashing behaviour changed to simple non-drawing. Regards, Stephen

Dec. 28, 2002

Another Wine OSS hang-at-end-of-playback bug

by Matt Chapman

Hi, I'm seeing some apps hang after playing an audio sample (even after the latest fix from Eric Pouech/Dan Kegel). I've tracked it down to the following. dwBufferSize is calculated from info->fragstotal * info->fragsize: wwo->dwBufferSize = info.fragstotal * info.fragsize; whereas dwPlayedTotal is calculated using info->bytes: wwo->dwPlayedTotal = wwo->dwWrittenTotal - (wwo->dwBufferSize - info->bytes); Thus the assumption is that, at beginning and end of playback, info->fragstotal * info->fragsize == info->bytes, so that wwo->dwPlayedTotal == wwo->dwWrittenTotal. But, for my soundcard (ymfpci driver), after asking for 15 frags * 1024 bytes the situation is: fragments = 15, fragstotal = 18, fragsize = 1024, bytes = 15612 i.e. info->fragstotal * info->fragsize = 18432, info->bytes = 15612 Thus dwPlayedTotal never reaches dwWrittenTotal and the last buffer never gets marked as done. Using info->bytes for wwo->dwBufferSize does fix my problem, not sure if there's a better solution. Matt [Looking at the driver, it looks like the difference is a safety margin to stop the DSP when it reaches the end. Arguably the driver should just report 15 in fragstotal and not bother applications with the detail that its buffer is actually 18 frags in size...] Index: dlls/winmm/wineoss/audio.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/wineoss/audio.c,v retrieving revision 1.68 diff -u -r1.68 audio.c --- dlls/winmm/wineoss/audio.c 15 Dec 2002 02:59:13 -0000 1.68 +++ dlls/winmm/wineoss/audio.c 28 Dec 2002 09:56:46 -0000 @@ -1357,7 +1357,7 @@ /* Remember fragsize and total buffer size for future use */ wwo->dwFragmentSize = info.fragsize; - wwo->dwBufferSize = info.fragstotal * info.fragsize; + wwo->dwBufferSize = info.bytes; wwo->dwPlayedTotal = 0; wwo->dwWrittenTotal = 0; wwo->bNeedPost = TRUE;

Dec. 28, 2002

DirectSound and i810 soundcards

by Francois Gouget

There is a problem with Directsound and i810 soundcards. The test I just sent to wine-patches illustrates it very well. Basically sounds are being played too fast. Here's my understanding of the problem (if my memory and understanding of the logs is correct): When DSound initializes it create a primary sound buffer and invokes winmm to actually get access to a sound device. The default format of the primary buffer is 22050x16x2 (i.e. 22050Hz, 16 bit sound, stereo). This means the device it's going to get will be handled by msacm.drv which will be responsible for performing the conversions on the fly. However during the primary buffer creation DSDB_MapPrimary gets invoked in wineoss and does an mmap of the hardware sound buffer. So when we then play sound in a secondary sound buffer, this sound gets mixed into the primary buffer, but because of the mmap this then goes straight to the sound card with no further conversion. So you end up with a chipmunk sound effect since you play a 22050x16x2 sound at 48000x16x2. I will try to make more tests to confirm this but does it seem to make sense? Should I look in some other direction? Any suggestion about a fix? If you have an i810 soundcard you can reproduce by doing the following: * apply "Add WINETEST_INTERACTIVE" from wine-patches * apply "Add 'audiophile' DirectSound tests" from wine-patches * cd dlls/dsound/tests * make * WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c (you can also set WINETEST_DEBUG=2 to get more debug info about the test's buffer management, though this is probably not relevant here) Alternately, you can download the latest Windows test binaries from my site (http://fgouget.free.fr/wine/winetests.zip) and run them using Wine, or on Windows: set WINETEST_INTERACTIVE=1 dsound_test dsound Actually I would be interested in the results of this test on Windows: * the test tone is usually played three times. Are all three, and especially the first one, at the right pitch? * what is the output of the test? I'm interested in reported capabilities as stated by Windows and Wine for instance (to determine whether the primary buffer is emulated for instance). * what is the primary buffer's default format? 22050x16x2? (that's not supported by the sound card!) * does the winmm test work? set WINETEST_INTERACTIVE=1 winmm_test wave * in particular, what happens when the test tone is played with WAVE_FORMAT_DIRECT on Windows? (except Win9x platforms which don't support that flag) -- Francois Gouget fgouget(a)codeweavers.com

Dec. 28, 2002

Fwd: Get rid of W->A calls: GetPrinterDriverDirectory (2nd)

by Stefan Leichter

Hello Alexandre, why is this patch still waiting to be applied? If something is wrong please tell it loud on the mailing list. Stefan ---------- Weitergeleitete Nachricht ---------- Subject: Fwd: Get rid of W->A calls: GetPrinterDriverDirectory Date: Sat, 21 Dec 2002 09:52:30 +0100 From: Stefan Leichter <Stefan.Leichter(a)camLine.com> To: wine-devel(a)winehq.com Hello, is there any reason why this patch did not made it into CVS & 20021219? Stefan ---------- Weitergeleitete Nachricht ---------- Subject: Get rid of W->A calls: GetPrinterDriverDirectory Date: Sun, 15 Dec 2002 10:24:44 +0100 From: Stefan Leichter <Stefan.Leichter(a)camLine.com> To: wine-patches(a)winehq.com Hello, after spending some days fixing the read-write errors on my DDYS-T18350 disk here a new patch Changelog ------------ moved implementation of GetPrinterDriverDirectory from ascii to unicode Index: dlls/winspool/info.c =================================================================== RCS file: /home/wine/wine/dlls/winspool/info.c,v retrieving revision 1.61 diff -u -r1.61 info.c --- dlls/winspool/info.c 12 Nov 2002 02:22:24 -0000 1.61 +++ dlls/winspool/info.c 15 Dec 2002 08:40:09 -0000 @@ -41,6 +41,7 @@ #include "winbase.h" #include "winerror.h" #include "winreg.h" +#include "winternl.h" #include "wine/windef16.h" #include "wine/unicode.h" #include "wine/debug.h" @@ -2390,23 +2391,23 @@ } /*************************************************************************** ** - * GetPrinterDriverDirectoryA [WINSPOOL.@] + * GetPrinterDriverDirectoryW [WINSPOOL.@] */ -BOOL WINAPI GetPrinterDriverDirectoryA(LPSTR pName, LPSTR pEnvironment, +BOOL WINAPI GetPrinterDriverDirectoryW(LPWSTR pName, LPWSTR pEnvironment, DWORD Level, LPBYTE pDriverDirectory, DWORD cbBuf, LPDWORD pcbNeeded) { DWORD needed; - TRACE("(%s, %s, %ld, %p, %ld, %p)\n", pName, pEnvironment, Level, - pDriverDirectory, cbBuf, pcbNeeded); + TRACE("(%s, %s, %ld, %p, %ld, %p)\n", debugstr_w(pName), + debugstr_w(pEnvironment), Level, pDriverDirectory, cbBuf, pcbNeeded); if(pName != NULL) { - FIXME("pName = `%s' - unsupported\n", pName); + FIXME("pName = `%s' - unsupported\n", debugstr_w(pName)); SetLastError(ERROR_INVALID_PARAMETER); return FALSE; } if(pEnvironment != NULL) { - FIXME("pEnvironment = `%s' - unsupported\n", pEnvironment); + FIXME("pEnvironment = `%s' - unsupported\n", debugstr_w(pEnvironment)); SetLastError(ERROR_INVALID_ENVIRONMENT); return FALSE; } @@ -2414,10 +2415,16 @@ WARN("Level = %ld - assuming 1\n", Level); /* FIXME should read from registry */ - needed = GetSystemDirectoryA(pDriverDirectory, cbBuf); + needed = GetSystemDirectoryW( (LPWSTR)pDriverDirectory, cbBuf/sizeof(WCHAR)); + /* GetSystemDirectoryW returns number of TCHAR without '\0' + * adjust this now + */ needed++; + needed*=sizeof(WCHAR); + if(pcbNeeded) *pcbNeeded = needed; + TRACE("required <%08lx>\n", *pcbNeeded); if(needed > cbBuf) { SetLastError(ERROR_INSUFFICIENT_BUFFER); return FALSE; @@ -2427,25 +2434,41 @@ /*************************************************************************** ** - * GetPrinterDriverDirectoryW [WINSPOOL.@] + * GetPrinterDriverDirectoryA [WINSPOOL.@] */ -BOOL WINAPI GetPrinterDriverDirectoryW(LPWSTR pName, LPWSTR pEnvironment, +BOOL WINAPI GetPrinterDriverDirectoryA(LPSTR pName, LPSTR pEnvironment, DWORD Level, LPBYTE pDriverDirectory, DWORD cbBuf, LPDWORD pcbNeeded) { - LPSTR pNameA = NULL, pEnvironmentA = NULL; + UNICODE_STRING nameW, environmentW; BOOL ret; - - if(pName) - pNameA = HEAP_strdupWtoA( GetProcessHeap(), 0, pName ); - if(pEnvironment) - pEnvironmentA = HEAP_strdupWtoA( GetProcessHeap(), 0, pEnvironment ); - ret = GetPrinterDriverDirectoryA( pNameA, pEnvironmentA, Level, - pDriverDirectory, cbBuf, pcbNeeded ); - if(pNameA) - HeapFree( GetProcessHeap(), 0, pNameA ); - if(pEnvironmentA) - HeapFree( GetProcessHeap(), 0, pEnvironmentA ); + DWORD pcbNeededW; + INT len = cbBuf * sizeof(WCHAR)/sizeof(CHAR); + WCHAR *driverDirectoryW = NULL; + + if (len) driverDirectoryW = HeapAlloc( GetProcessHeap(), 0, len ); + + if(pName) RtlCreateUnicodeStringFromAsciiz(&nameW, pName); + else nameW.Buffer = NULL; + if(pEnvironment) RtlCreateUnicodeStringFromAsciiz(&environmentW, pEnvironment); + else environmentW.Buffer = NULL; + + ret = GetPrinterDriverDirectoryW( nameW.Buffer, environmentW.Buffer, Level, + (LPBYTE)driverDirectoryW, len, &pcbNeededW ); + if (ret) { + ret = WideCharToMultiByte( CP_ACP, 0, driverDirectoryW, -1, + pDriverDirectory, cbBuf, NULL, NULL); + *pcbNeeded = WideCharToMultiByte( CP_ACP, 0, driverDirectoryW, -1, + NULL, 0, NULL, NULL); + } else + *pcbNeeded = pcbNeededW * sizeof(CHAR)/sizeof(WCHAR); + + TRACE("provided<%ld> required <%ld>\n", cbBuf, *pcbNeeded); + + if(driverDirectoryW) + HeapFree( GetProcessHeap(), 0, driverDirectoryW ); + RtlFreeUnicodeString(&environmentW); + RtlFreeUnicodeString(&nameW); return ret; } ------------------------------------------------------- -------------------------------------------------------

Dec. 28, 2002

Re: Documentation work -task list -man pages

by Tom Wickline

Dimitrie O. Paun wrote: > On December 26, 2002 05:31 pm, Tony Lambregts wrote: > >>I think that we should keep the documentation tasks togetther. If its OK >>with Dimi we can just use his page and give him diffs or we can split >>off the documentation section and he can link to it. > > > I am more than OK with it, I think it's the way to go. Having the TODO > split in 1000 places defeats the purpose of having a TODO list in the > first place. Moreover, look at the other TODOs: they don't change that > often... :) OK....... Fine with me can we just break this down to smaller task ? One huge task is a bit overwhelming to a would be helper. And if this was broke down to smaller task more people might want to take over a small manageable task IMHO. Tom

Dec. 28, 2002