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

UMR in CRYPT_RemoveStringFromMultiString()
by Dan Kegel Nov. 19, 2009

Nov. 19, 2009

Hi Juan, http://kegel.com/wine/valgrind/logs/2009-11-18-21.51/vg-crypt32_oid.txt says Invalid read of size 1 at memmove (mc_replace_strmem.c:613) by CRYPT_RemoveStringFromMultiString (oid.c:885) by CryptUnregisterDefaultOIDFunction (oid.c:1010) by test_registerDefaultOIDFunction (oid.c:437) by func_oid (oid.c:601) by run_test (test.h:535) by main (test.h:585) Address 0x7f040ed4 is 0 bytes after a block of size 44 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by CryptMemAlloc (main.c:125) by CRYPT_GetDefaultOIDDlls (oid.c:930) by CryptUnregisterDefaultOIDFunction (oid.c:1009) by test_registerDefaultOIDFunction (oid.c:437) This is near the code changed in crypt32: Don't copy past end of buffer when removing the last string in a multistring. - Dan

1 0

Re: Difficulties with Regression Testing
by James Mckenzie Nov. 19, 2009

Nov. 19, 2009

Austin English wrote: > >On Thu, Nov 19, 2009 at 9:41 AM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >>>From: Austin English <austinenglish(a)gmail.com> >>>Sent: Nov 19, 2009 10:31 AM >>>To: James Mckenzie <jjmckenzie51(a)earthlink.net> >>>Cc: Wine Development Mailing List <wine-devel(a)winehq.org> >>>Subject: Re: Difficulties with Regression Testing >>> >>>On Thu, Nov 19, 2009 at 8:51 AM, James Mckenzie >>><jjmckenzie51(a)earthlink.net> wrote: >>>> All: >>>> >>>> I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE >>>> patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the >>>> instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different >>>> problems: >>>> >>>> 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of >>>> any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes >>>> the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct >>>> wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build >>>> makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine >>>> includes are not included. >>> >>>Try doing a make clean / make distclean. >>> >> I don't think this will do anything, but I'll try it. > >Ah, Makefile.in...nm, misread that. Not sure then. > Thanks for the thought. It is absolutely strange as this just started happening. I correct the Git and it happens after a few more tries at git bisect. Maybe something did change the file between wine-1.1.10 and wine-1.1.11 that git bisect corrupts. I'll be looking at this after the long ride this weekend and over the holiday next weekend. >>>> 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect >>>> good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in >>>> the tools/subdirectory. >>> >>>IIRC, that was a file for the cryptui manager that AJ forgot to >>>include with the commit needing it. Try either putting it there >>>manually from another git branch, or using make -k. >>> >> Where does this need to be added? I might be able to figure it out, but I don't want to go guessing. > >Put it in dlls/cryptui/, or just use make -k to ignore it. > Thank you. I'll put it there and then try the build again. James McKenzie

1 0

Re: shell32: deal better with spaces in ASSOCSTR_COMMAND values
by Alexandre Julliard Nov. 19, 2009

Nov. 19, 2009

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > @@ -324,7 +324,14 @@ static HRESULT ASSOC_GetExecutable(IQueryAssociationsImpl *This, > else > { > pszStart = pszCommand; > - pszEnd = strchrW(pszStart, ' '); > + for (pszEnd = pszStart; (pszEnd = strchrW(pszEnd, ' ')); pszEnd++) > + { > + WCHAR c = *pszEnd; > + *pszEnd = 0; > + if (SearchPathW(NULL, pszStart, NULL, pathlen, path, NULL)) > + break; > + *pszEnd = c; You have a redundant SearchPath call now. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winspool.drv: Acroread 9.2 relies on the buffer sizes returned by GetPrinterA and GetPrinterDriverA being large enough to hold their respective unicode versions' data.
by Alexandre Julliard Nov. 19, 2009

Nov. 19, 2009

Huw Davies <huw(a)codeweavers.com> writes: > --- > dlls/winspool.drv/info.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) This doesn't work here: ../../../tools/runtest -q -P wine -M winspool.drv -T ../../.. -p winspool.drv_test.exe.so info.c && touch info.ok info.c:2269: Test failed: needed 38 != filled 21 info.c:2269: Test failed: needed 414 != filled 219 info.c:2269: Test failed: needed 438 != filled 239 info.c:2269: Test failed: needed 446 != filled 245 info.c:2269: Test failed: needed 426 != filled 231 info.c:2269: Test failed: needed 482 != filled 281 make: *** [info.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

1 0

Difficulties with Regression Testing
by James Mckenzie Nov. 19, 2009

Nov. 19, 2009

All: I've been running regression tests to find a commit between wine-1.1.10 and wine-1.1.11 that breaks the EM_FORMATRANGE patch or to discover what I need to do to fix the patch to make it work with wine-1.1.11. I've been following the instructions on the Regression Testing Wiki page. I am on the fourth git bisect good and I run into two different problems: 1. The tools/Makefile.in file gets corrupted on the fourth git bisect good. This is unexpected as I am not aware of any changes to this file that would cause corruption. This happens interrmittently and a git fetch sometimes causes the error that tools/Makefile.in needs to be updated to appear when I apply/remove a patch which is needed to correct wordpad, one of the programs I am using to test the EM_FORMATRANGE patch. The build fails when attempting to build makedep.c. The includes appear to be incorrect and do not pick up the files in the source directory thus the Wine includes are not included. 2. Something else is causing the check.bmp file not to be found and thus the tests fail on the fourth git bisect good. The .rc file that calls this file is located in two different directorys but the check.bmp file only exists in the tools/subdirectory. Can anyone confirm/deny that they are experiencing the same problems with a git build? Thank you.

2 1

Wine Icons - final round
by Joel Holdsworth Nov. 19, 2009

Nov. 19, 2009

Hi All, I wanted to fill you in on the progress on the Tango icon set. You can see it here: http://www.airwebreathe.org.uk/wine-icon/ Please let me know what you think - or if you have any comments. After the last two rounds, I'm hoping that we should basically be at a stage where most people are happy. The main change since last time is that I've replaced the user32 icons with icons that are similar to the Windows 7/Vista standard - but Tango compliant. I was unable to clarify the license for the icon I was using for the ramdisk icon, so I redrew one of my own - a DIMM, which in the end is more suitable than the SOIC chip we had before. The other major change is that I've decided to hold off on cryptui.dll. I'm not happy with the artwork yet, and cryptui.dll needs to be modified so that it uses HICONs rather the HBITMAPs, which don't cope with different colour depths well. When everyone is happy, I really need to freeze the icons from further modifications, because I need to begin the laborious process of making 8 and 4-bit versions. If anyone would like to help with this I'd be happy to have some helpers. But for now let me know if you have any thoughts. Best Regards Joel Holdsworth

3 2

Re: Problem to download git
by James Mckenzie Nov. 19, 2009

Nov. 19, 2009

> >> error: Unable to get pack file http://source.winehq.org/git/wine.git/objects/pack/pack- >>7c2ab792c6e1c8f603b784f9dcb81f56f03bbf75.pack > >Is this on a Mac, by any chance? I had similar problems using >MacPorts's git with a proxy server. I also had Linux running in a VM >on that machine, and fetching from the Linux VM always succeeded. The >odd thing is, fetching from Linux also fixed the MacPorts git fetch >for me, at least until the next day's update. > >If this isn't on a Mac, I don't know what to tell you. Mine was. I don't think Dan has a Mac though. It looks like the Git server was being a problem last night. I had to pull a full git as I thought that I had messed mine up. More on this in a separate message. James McKenzie

1 0

Re: Problem to download git
by James Mckenzie Nov. 19, 2009

Nov. 19, 2009

>On Wed, Nov 18, 2009 at 11:22 PM, Dan Kegel <dank(a)kegel.com> wrote: >> I'm having network errors with git tonight, too. e.g. >> >> $ git pull >> fatal: The remote end hung up unexpectedly >> >> >> > >Hangs up about half the time for me too tonight. > +1. The second pull worked. James McKenzie

1 0

Re: [PATCH 4/5] comctl32/tests: Add further tests for IImageList
by Paul Vriens Nov. 19, 2009

Nov. 19, 2009

On 11/13/2009 06:14 PM, Owen Rudge wrote: > --- > dlls/comctl32/tests/imagelist.c | 80 > +++++++++++++++++++++++++++++++++++++++ > 1 files changed, 80 insertions(+), 0 deletions(-) > Hi Owen, These tests introduce 3 failures on all 32bit XP boxes: http://test.winehq.org/data/tests/comctl32:imagelist.html Could you have a look? -- Cheers, Paul.

3 3

Test for Bug 4543: Testers needed
by Charles Davis Nov. 19, 2009

Nov. 19, 2009

Hi, I have a test that I wrote from scratch for bug 4543. It tests the operation of BitBlt to a metafile, first from the screen then pure whiteness. Unfortunately, I have no Windows boxes to test on, so I need people to run my test on Windows. After all, I need to verify that this test is an accurate representation of Windows' behavior! Also, testing under Wine would be appreciated. As a Mac user, I don't think my system is representative of the vast majority of Wine users (who probably run Linux). I've attached the patch so you can build a gdi32_test.exe that contains my tests. Thanks in advance. Chip >From db073155c888747b9259cb8fe0d5ff2a59ee5666 Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 68 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 68 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..6bf25e4 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -665,6 +665,74 @@ static void test_SaveDC(void) DestroyWindow(hwnd); } +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + *pi++; + if(*pi > 2) return 1; + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); + if(*pi == 1) /* First BitBlt */ + { + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); + } + else + { + ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); + } + return 1; +} + +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile; + HENHMETAFILE hMetafile; + ENHMETAHEADER emh; + BYTE *bits; + BOOL ret; + UINT i; + + hdcDisplay = CreateDCA(NULL, "DISPLAY", NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA error %d\n", GetLastError() ); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcDisplay, 0, 0, SRCCOPY); + ok( ret, "BitBlt error %d\n", GetLastError() ); + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt error %d\n", GetLastError() ); + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile error %d\n", GetLastError() ); + + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); + ok( ret != 0, "GetEnhMetaFileHeader error %d\n", GetLastError() ); + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); + + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); + if(!bits) + { + skip( "not enough memory for EMF bits\n" ); + return; + } + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); + for(i = 0; i < emh.nBytes; i++) + ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); + + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, (LPARAM)&i, NULL); + ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); +} + static void test_mf_SaveDC(void) { HDC hdcMetafile; -- 1.6.5.2

3 14

Wineconf?
by Damjan Jovanovic Nov. 19, 2009

Nov. 19, 2009

Hi Can someone please write a bit about Wineconf 2009, for those of us that didn't go? Also is there videos/presentations to see? Thank you Damjan Jovanovic

4 7

switching to redmine?
by Dan Kegel Nov. 19, 2009

Nov. 19, 2009

http://yokozar.org/blog/archives/171 is a nice writeup (thanks Scott) of wineconf. It all sounds good except for that switching to redmine part... The current wiki and bugzilla are working reasonably well, doesn't seem worth the disruption to switch. I'm highly skeptical of these newfangled wiki+bugzilla+scm+mailinglist thingies. It's really hard to do all those jobs well. Sourceforge was the first, and it was really rough. Google Code is kind of ok, but it doesn't support git yet, and its svn has performance issues (for the moment). Launchpad is also kind of ok, and kind of supports git... Yet Another WBSM Thingy that I've never heard of seems unlikely to be as robust as the above systems. - Dan

3 2

Buffer overrun in LsaLookupNames2() found with valgrind+wine+new heap patch
by Dan Kegel Nov. 19, 2009

Nov. 19, 2009

Here's the first error it helped Valgrind find in tonight's automated run: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so lsa.c && touch lsa.ok ... Invalid write of size 1 at memmove (mc_replace_strmem.c:613) by RtlCopySid (sec.c:376) by CopySid (security.c:905) by lookup_local_wellknown_name (security.c:2800) by lookup_name (lsa.c:308) by LsaLookupNames2 (lsa.c:411) by test_LsaLookupNames2 (lsa.c:336) by func_lsa (lsa.c:362) Address 0x7f03c550 is 6 bytes after a block of size 26 alloc'd at notify_alloc (heap.c:279) by RtlAllocateHeap (heap.c:1521) by LsaLookupNames2 (lsa.c:402) by test_LsaLookupNames2 (lsa.c:336) by func_lsa (lsa.c:362) Offhand that looks like a real problem. Aric, you may have touched that code last, could you have a look? Oh, and here's a bit that was missing from the patch. - Dan

1 0

re: Problem to download git
by Dan Kegel Nov. 18, 2009

Nov. 18, 2009

I'm having network errors with git tonight, too. e.g. $ git pull fatal: The remote end hung up unexpectedly

2 1

ntdll: implement FLG_HEAP_ENABLE_TAIL_CHECK
by Dan Kegel Nov. 18, 2009

Nov. 18, 2009

(Without a change like this, Valgrind can't properly detect buffer overruns, but even without Valgrind, this change will improve Wine's ability to detect buffer overruns.) With this change, users can enable buffer overrun detection in Wine by setting WINE_GLOBAL_FLAGS=0x10. This is like the overrun detection in Windows enabled by setting NtGlobalFlags to 0x10, but checks 16 bytes rather than 8, and works for large allocations, not just small ones. With this enabled, a remarkable number of tests break. I'm posting this to wine-devel for review while I add valgrind annotations (which should make it easier to tell whether the errors it detects are real or spurious) and fix the spurious breakages. Note that this change is a no-op under normal circumstances; without setting WINE_GLOBAL_FLAGS, you shouldn't see any breakage.

2 4

Resetting screen resolution on crash
by Erich Hoover Nov. 18, 2009

Nov. 18, 2009

I was reading the brief summary on WineConf ( http://yokozar.org/blog/archives/171) and saw an interesting item: > We need some help from Freedesktop.org for solving bug 10841. Essentially > we need a standard way of saying “hey reset the resolution when I’m done, > even if I crash.” I was “volunteered” for the task of approaching the > respective projects. I believe this is a case that we can detect on our own, attached is a small standalone example of using fork() in such a way that you could reset the screen resolution even if an application crashed. Erich Hoover ehoover(a)mines.edu

2 1

Re: [PATCH 6/6] msxml3: Implemented xmlnode_get_nodeTypedValue date related data types handling
by Paul Vriens Nov. 18, 2009

Nov. 18, 2009

On 11/18/2009 12:51 AM, Piotr Caban wrote: > --- > dlls/msxml3/node.c | 67 ++++++++++++++++++++++++++++++++++++++++ > dlls/msxml3/tests/domdoc.c | 72 > ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 139 insertions(+), 0 deletions(-) > > Hi Piotr, These new tests introduce failures on XP and W2K3: http://test.winehq.org/data/tests/msxml3:domdoc.html (These two are the only platforms in as of this writing). Could you have a look? -- Cheers, Paul.

1 0

Re: ole32: Add a test for freeing the parent of an open stream.
by Alexandre Julliard Nov. 18, 2009

Nov. 18, 2009

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > From 1d583fc07db661bd0f0d0d00ea82c6208c3b744f Mon Sep 17 00:00:00 2001 > From: Vincent Povirk <vincent(a)codeweavers.com> > Date: Tue, 17 Nov 2009 11:20:34 -0600 > Subject: [PATCH 4/7] ole32: Add a test for freeing the parent of an open stream. It doesn't work here: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so storage32.c && touch storage32.ok wine: Unhandled page fault on read access to 0x454556d6 at address 0x687dc2dd (thread 0045), starting debugger... Unhandled exception: page fault on read access to 0x454556d6 in 32-bit code (0x687dc2dd). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:687dc2dd ESP:0032f980 EBP:0032f9b8 EFLAGS:00010216( R- -- I -A-P- ) EAX:45455246 EBX:688587e4 ECX:00110058 EDX:00000100 ESI:45455246 EDI:00000011 Stack dump: 0x0032f980: 00000000 00000100 00000000 00000080 0x0032f990: 0032f9dc 0032f9b0 0032f9b8 7bc45af1 0x0032f9a0: 00000040 00040000 00141c80 7bc346cf 0x0032f9b0: 00141c58 688587e4 0032fa68 687dc339 0x0032f9c0: 45455246 00000002 0032f9dc 00000000 0x0032f9d0: 00000000 0032f9dc 00000000 00000000 Backtrace: =>0 0x687dc2dd StorageImpl_ReadRawDirEntry+0x3d(This=0x45455246, index=256, buffer="") [/home/julliard/wine/wine/dlls/ole32/storage32.c:3002] in ole32 (0x0032f9b8) 1 0x687dc339 StorageImpl_ReadDirEntry+0x39(This=0x45455246, index=2, buffer=0x32fa98) [/home/julliard/wine/wine/dlls/ole32/storage32.c:3127] in ole32 (0x0032fa68) 2 0x687d8268 StgStreamImpl_SetSize+0x98(iface=<register ESI not in topmost frame>, libNewSize=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/stg_stream.c:614] in ole32 (0x0032fb28) 3 0x687d86ee StgStreamImpl_Write+0x1ce(iface=0x141cd8, pv=0x6867cadc, cb=17, pcbWritten=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/stg_stream.c:420] in ole32 (0x0032fb78) 4 0x68662ea2 test_parent_free+0x222() [/home/julliard/wine/wine/dlls/ole32/tests/storage32.c:1322] in ole32_test (0x0032fbc8) 5 0x6866deea func_storage32+0x14ca() [/home/julliard/wine/wine/dlls/ole32/tests/storage32.c:2470] in ole32_test (0x0032fd98) 6 0x68671b40 run_test+0x130(name="storage32.c") [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:537] in ole32_test (0x0032fdd8) 7 0x68671d2e main+0x11e(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:586] in ole32_test (0x0032fe88) 8 0x686727b4 __wine_spec_exe_entry+0x84(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ole32_test (0x0032feb8) 9 0x7b8768a5 start_process+0x55(peb=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1025] in kernel32 (0x0032fee8) 10 0x7bc6de64 call_thread_func+0xc() in ntdll (0x0032fef8) 11 0x7bc6e080 call_thread_entry_point+0x70(entry=0x7b876850, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2342] in ntdll (0x0032ffc8) 12 0x7bc4b20a in ntdll (+0x3b20a) (0x0032ffe8) 13 0x68027e4d wine_call_on_stack+0x1d() in libwine.so.1 (0x00000000) 0x687dc2dd StorageImpl_ReadRawDirEntry+0x3d [/home/julliard/wine/wine/dlls/ole32/storage32.c:3002] in ole32: movl 0x490(%eax),%eax 3002 hr = BlockChainStream_ReadAt( -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: To error out or to skip tests?
by Greg Geldorp Nov. 18, 2009

Nov. 18, 2009

Hi Jörg > > The picture on test.winehq.org is a disaster: None of the w95, w98, nt4, > > 2k, 2k3, Vista, 2k8, w7 machines have performed winmm:wave tests! > > They all have no sound configured. Mostly useless. > > A lot of those VMware boxes are mine. They come in two flavors. Some of > them (starting with esx-) are ESX VMs, ESX is VMware's data center product, > which simply doesn't support sound. The others (starting with gvg-) are > Server VMs, which do support sound. The reason I didn't configure sound > on them is because I'm simply not interested in sound. I'll consider > enabling sound, but to be honest I'm a bit put off by your aggressive tone. > > Anyway, the end result is that there will always be ESX VMs that can't > run sound tests. After a bit of mucking around I got sound to work on the Linux host where those VMware Server VMs run, and enabled sound in the VMs where possible. I could not find correct sound drivers for some of the old stuff (NT4 and below), so those still don't have sound, neither do the ESX VMs. Best regards, Ge.

3 2

Re: advapi32/tests: Skip tests for ACL file info if ACL info not stored (try 2)
by Alexandre Julliard Nov. 18, 2009

Nov. 18, 2009

Austin Lund <austin.lund(a)gmail.com> writes: > @@ -3143,6 +3146,13 @@ static void test_GetSecurityInfo(void) > return; > } > > + if (GetVolumePathName(myARGV[0], volumepathname, 50) && > + GetVolumeInformation(volumepathname, NULL, 0, NULL, NULL, &filesystemflags, NULL, 0) && > + (filesystemflags & FILE_PERSISTENT_ACLS)) > + { > + testacl = TRUE; > + } Testing file system flags is not a good idea, that won't work on Wine. It's better to test the results of the actual call. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: advapi32/tests: Skip tests for ACL file info if ACL info not stored (try 2)
by Paul Vriens Nov. 18, 2009

Nov. 18, 2009

On 11/18/2009 09:54 AM, Austin Lund wrote: > + TCHAR volumepathname[50]; Please don't use TCHAR's. > + BOOL testacl = FALSE; > + DWORD filesystemflags; > > if (!pGetSecurityInfo) > { > @@ -3143,6 +3146,13 @@ static void test_GetSecurityInfo(void) > return; > } > > + if (GetVolumePathName(myARGV[0], volumepathname, 50)&& > + GetVolumeInformation(volumepathname, NULL, 0, NULL, NULL,&filesystemflags, NULL, 0)&& > + (filesystemflags& FILE_PERSISTENT_ACLS)) > + { > + testacl = TRUE; > + } GetVolumePathName is not available before W2K so you should use GetProcAddress here and bail out or skip() if the function is not available. It's also probably better to use the explicit A-versions for both calls. -- Cheers, Paul.

1 0

Re: Test for Bug 4543: Testers needed
by Charles Davis Nov. 17, 2009

Nov. 17, 2009

Vincent Povirk wrote: > You still have the loop comparing to 0xff, and the test won't pass on > windows with the if(0). Whoops, that must have been an old version of the patch. I fixed the first one, and the second one should be fixed, too. Now the BitBlt(...,WHITENESS) call executes on Windows, but not on Wine. (There should be a function in wine/test.h for doing this.) Patch attached. > > On Tue, Nov 17, 2009 at 6:09 PM, Charles Davis <cdavis(a)mymail.mines.edu> wrote: >> All right, this should be the last one. The tests pass on Wine, and >> should pass on Windows if you un-if(0) the call to BitBlt(..., >> WHITENESS). I still don't have any results for the many other Windows >> versions (95, 98, ME, NT4, 2000, Vista, Win7), so I'm going to wait for >> results from these other platforms before I send this to wine-patches. >> >> Chip >> >> >> From 2d5aa7c607496c1b05a7a08adfee09db446754cb Mon Sep 17 00:00:00 2001 >> From: Charles Davis <cdavis(a)mymail.mines.edu> >> Date: Tue, 17 Nov 2009 11:10:50 -0700 >> Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. >> To: wine-patches <wine-patches(a)winehq.org> >> Reply-To: wine-devel <wine-devel(a)winehq.org> >> >> --- >> dlls/gdi32/tests/metafile.c | 83 +++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 83 insertions(+), 0 deletions(-) >> >> diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c >> index b559901..19401ed 100644 >> --- a/dlls/gdi32/tests/metafile.c >> +++ b/dlls/gdi32/tests/metafile.c >> @@ -665,6 +665,88 @@ static void test_SaveDC(void) >> DestroyWindow(hwnd); >> } >> >> +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) >> +{ >> + UINT *pi = (UINT *)data; >> + EMRBITBLT *emrbb; >> + >> + if(emfr->iType != EMR_BITBLT) return 1; >> + emrbb = (EMRBITBLT *)emfr; >> + >> + (*pi)++; >> + if(*pi > 2) return 1; >> + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); >> + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); >> + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); >> + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); >> + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); >> + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); >> + if(*pi == 1) /* First BitBlt */ >> + { >> + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); >> + } >> + else >> + { >> + todo_wine ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); >> + } >> + return 1; >> +} >> + >> +static void test_emf_BitBlt(void) >> +{ >> + HDC hdcDisplay, hdcMetafile, hdcBitmap; >> + HBITMAP hBitmap, hOldBitmap; >> + HENHMETAFILE hMetafile; >> + ENHMETAHEADER emh; >> + BYTE *bits; >> + BOOL ret; >> + UINT i; >> + >> + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); >> + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); >> + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); >> + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); >> + >> + hdcBitmap = CreateCompatibleDC(hdcDisplay); >> + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); >> + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); >> + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); >> + hOldBitmap = SelectObject(hdcBitmap, hBitmap); >> + >> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); >> + ok( ret, "BitBlt failed\n" ); >> + if(0) /* Crashes on wine */ >> + { >> + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); >> + ok( ret, "BitBlt failed\n" ); >> + } >> + >> + hMetafile = CloseEnhMetaFile(hdcMetafile); >> + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); >> + >> + ret = GetEnhMetaFileHeader( hMetafile, sizeof(emh), &emh ); >> + ok( ret != 0, "GetEnhMetaFileHeader failed\n" ); >> + ok( emh.dSignature == ENHMETA_SIGNATURE, "bad metafile signature %x\n", emh.dSignature ); >> + >> + bits = HeapAlloc( GetProcessHeap(), 0, emh.nBytes ); >> + if(!bits) >> + { >> + skip( "not enough memory for EMF bits\n" ); >> + return; >> + } >> + ret = GetEnhMetaFileBits( hMetafile, emh.nBytes, bits ); >> + ok( ret != 0, "GetEnhMetaFileBits error %d\n", GetLastError() ); >> + for(i = 0; i < emh.nBytes; i++) >> + todo_wine ok( bits[i] == 0xff, "unexpected EMF bits: got %02x, expected 0xff\n", bits[i] ); >> + >> + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, &i, NULL); >> + todo_wine ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); >> + >> + SelectObject(hdcBitmap, hOldBitmap); >> + DeleteObject(hBitmap); >> + DeleteDC(hdcBitmap); >> +} >> + >> static void test_mf_SaveDC(void) >> { >> HDC hdcMetafile; >> @@ -2628,6 +2710,7 @@ START_TEST(metafile) >> /* For enhanced metafiles (enhmfdrv) */ >> test_ExtTextOut(); >> test_SaveDC(); >> + test_emf_BitBlt(); >> >> /* For win-format metafiles (mfdrv) */ >> test_mf_SaveDC(); >> -- >> 1.6.5.2 >> >> >> > > > Chip >From 990018e6e74279c3243d2c3b48472e94d8839c8c Mon Sep 17 00:00:00 2001 From: Charles Davis <cdavis(a)mymail.mines.edu> Date: Tue, 17 Nov 2009 11:10:50 -0700 Subject: [PATCH] gdi32/tests: Test BitBlt() to a metafile. To: wine-patches <wine-patches(a)winehq.org> Reply-To: wine-devel <wine-devel(a)winehq.org> --- dlls/gdi32/tests/metafile.c | 67 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 67 insertions(+), 0 deletions(-) diff --git a/dlls/gdi32/tests/metafile.c b/dlls/gdi32/tests/metafile.c index b559901..dbeff43 100644 --- a/dlls/gdi32/tests/metafile.c +++ b/dlls/gdi32/tests/metafile.c @@ -665,6 +665,72 @@ static void test_SaveDC(void) DestroyWindow(hwnd); } +static int CALLBACK test_BitBlt_record(HDC hdc, HANDLETABLE *table, const ENHMETARECORD *emfr, int nobj, LPARAM data) +{ + UINT *pi = (UINT *)data; + EMRBITBLT *emrbb; + + if(emfr->iType != EMR_BITBLT) return 1; + emrbb = (EMRBITBLT *)emfr; + + (*pi)++; + if(*pi > 2) return 1; + ok( emrbb->xDest == 0, "wrong xDest for BitBlt record: got %d, expected 0\n", emrbb->xDest ); + ok( emrbb->yDest == 0, "wrong yDest for BitBlt record: got %d, expected 0\n", emrbb->yDest ); + ok( emrbb->xSrc == 0, "wrong xSrc for BitBlt record: got %d, expected 0\n", emrbb->xSrc ); + ok( emrbb->ySrc == 0, "wrong ySrc for BitBlt record: got %d, expected 0\n", emrbb->ySrc ); + ok( emrbb->cxDest == GetSystemMetrics(SM_CXSCREEN), "wrong cxDest for BitBlt record: got %d\n", emrbb->cxDest ); + ok( emrbb->cyDest == GetSystemMetrics(SM_CYSCREEN), "wrong cyDest for BitBlt record: got %d\n", emrbb->cyDest ); + if(*pi == 1) /* First BitBlt */ + { + ok( emrbb->dwRop == SRCCOPY, "wrong ROP for BitBlt record: got %x, expected SRCCOPY\n", emrbb->dwRop ); + } + else + { + todo_wine ok( emrbb->dwRop == WHITENESS, "wrong ROP for BitBlt record: got %x, expected WHITENESS\n", emrbb->dwRop ); + } + return 1; +} + +static void test_emf_BitBlt(void) +{ + HDC hdcDisplay, hdcMetafile, hdcBitmap; + HBITMAP hBitmap, hOldBitmap; + HENHMETAFILE hMetafile; + BOOL ret; + UINT i; + + hdcDisplay = CreateDCA("DISPLAY", NULL, NULL, NULL); + ok( hdcDisplay != 0, "CreateDCA error %d\n", GetLastError() ); + hdcMetafile = CreateEnhMetaFileA(hdcDisplay, NULL, NULL, NULL); + ok( hdcMetafile != 0, "CreateEnhMetaFileA failed\n" ); + + hdcBitmap = CreateCompatibleDC(hdcDisplay); + ok( hdcBitmap != 0, "CreateCompatibleDC failed\n" ); + hBitmap = CreateCompatibleBitmap(hdcDisplay, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN)); + ok( hBitmap != 0, "CreateCompatibleBitmap failed\n" ); + hOldBitmap = SelectObject(hdcBitmap, hBitmap); + + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), hdcBitmap, 0, 0, SRCCOPY); + ok( ret, "BitBlt failed\n" ); + if(0) /* Crashes on wine */ + { + ret = BitBlt(hdcMetafile, 0, 0, GetSystemMetrics(SM_CXSCREEN), GetSystemMetrics(SM_CYSCREEN), 0, 0, 0, WHITENESS); + ok( ret, "BitBlt failed\n" ); + } + + hMetafile = CloseEnhMetaFile(hdcMetafile); + ok( hMetafile != 0, "CloseEnhMetaFile failed\n" ); + + i = 0; + EnumEnhMetaFile(0, hMetafile, test_BitBlt_record, &i, NULL); + todo_wine ok( i == 2, "too many/not enough BitBlt records: got %d, expected 2\n", i ); + + SelectObject(hdcBitmap, hOldBitmap); + DeleteObject(hBitmap); + DeleteDC(hdcBitmap); +} + static void test_mf_SaveDC(void) { HDC hdcMetafile; @@ -2628,6 +2694,7 @@ START_TEST(metafile) /* For enhanced metafiles (enhmfdrv) */ test_ExtTextOut(); test_SaveDC(); + test_emf_BitBlt(); /* For win-format metafiles (mfdrv) */ test_mf_SaveDC(); -- 1.6.5.2

1 0

Re: today's git broke winetricks gecko :-(
by James Mckenzie Nov. 17, 2009

Nov. 17, 2009

Jacek Caban wrote: >Sent: Nov 17, 2009 7:40 AM >To: Tom Wickline <twickline(a)gmail.com> >Cc: James Mckenzie <jjmckenzie51(a)earthlink.net>, Vincent Povirk <madewokherd+8cd9(a)gmail.com>, wine-devel(a)winehq.org >Subject: Re: today's git broke winetricks gecko :-( > >Tom Wickline wrote: >> >> >> On Tue, Nov 17, 2009 at 10:27 PM, James Mckenzie >> <jjmckenzie51(a)earthlink.net <mailto:jjmckenzie51(a)earthlink.net>> wrote: >> >> >> > >> +1 as well. Not all UNIXes have Gecko support packages built for them >> >> >> +1 as well, I haven't tested the changes on OpenSolaris yet, but I >> plan to. :) > >Which makes -0 from both of you as you clearly don't understand the way >Gecko package works. These are .dll files so they are only arch >dependent from Wine point of view. Are there not installer packages for the different UNIXes for Gecko? If there are not, then the package should install everywhere, including MacOSX and OpenSolaris. If they are system/OS dependent, then my comment stands. James McKenzie

5 8

Re: flaky uninit variable in jscript
by Dan Kegel Nov. 17, 2009

Nov. 17, 2009

There was a second new error in that file that is probably low hanging fruit: Conditional jump or move depends on uninitialised value(s) at invoke_constructor (function.c:243) by Function_value (function.c:521) by invoke_prop_func (dispex.c:259) by jsdisp_call (dispex.c:870) by disp_call (dispex.c:899) by new_expression_eval (engine.c:1568) by expr_eval (engine.c:42) by assign_expression_eval (engine.c:3110) by expr_eval (engine.c:42) by expression_statement_eval (engine.c:679) by stat_eval (engine.c:37) by exec_source (engine.c:473) by exec_global_code (jscript.c:107) by JScriptParse_ParseScriptText (jscript.c:717) by parse_script (run.c:765) by run_from_res (run.c:908) by run_tests (run.c:1057) by func_run (run.c:1095) by run_test (test.h:535) by main (test.h:585) Uninitialised value was created by a stack allocation at invoke_constructor (function.c:227) Both are still happening as of the last run I have, http://kegel.com/wine/valgrind/logs/2009-11-17-07.31/vg-jscript_run.txt - Dan On Thu, Nov 5, 2009 at 7:25 PM, Dan Kegel <dank(a)kegel.com> wrote: > Hi Jacek, > could you have a look at this? I think there are some variants that > aren't being > cleanly initialized. > > http://kegel.com/wine/valgrind/logs/2009-11-05-09.09/diff-jscript_run.txt > http://kegel.com/wine/valgrind/logs/2009-11-05-09.09/vg-jscript_run.txt > > Conditional jump or move depends on uninitialised value(s) > at VARIANT_ValidateType (variant.c:546) > by VariantClear (variant.c:599) > by exec_global_code (jscript.c:111) > by JScriptParse_ParseScriptText (jscript.c:717) > by parse_text (script.c:624) > by parse_inline_script (script.c:679) > by parse_script_elem (script.c:703) > by doc_insert_script (script.c:817) > by nsRunnable_Run (mutation.c:464) > by ??? > by ??? > by add_script_runner (mutation.c:196) > by push_mutation_queue (mutation.c:253) > by nsDocumentObserver_DoneAddingChildren (mutation.c:684) > by ??? > by ??? > by ??? > by ??? > by ??? > by ??? > Uninitialised value was created by a stack allocation > at exec_global_code (jscript.c:94) > > Thanks, > Dan >

1 0

re: Working on avifil32, sudden "non enough memory" error
by Dan Kegel Nov. 17, 2009

Nov. 17, 2009

Julius wrote: >With one file however (GOODTIME.AVI from the win95 cd) I get this > error after about a second: > err:heap:HEAP_ValidateInUseArena Heap 0x110000: in-use arena 0x184420 > next block has PREV_FREE flag > non enough memory > > I have no idea where this comes from and why it happens. (It appears to > be unrelated to the memcpy call in avifile.c around line 1114.) With > +heap I also get this before the error: > HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. > (the assert fails) Sounds like heap corruption. You might want to cut down the file to the shortest one that causes the crash, then go after it (possibly using valgrind or the like) to look for the error. Does your implementation of avifil32 and friends work properly on windows?

3 3