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

Re: wshom.ocx: Added IDispatch support for IWshShell3
by Marvin Dec. 29, 2011

Dec. 29, 2011

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=16191 Your paranoid android. === WINEBUILD (build) === Can't determine base name

2 1

Re: include: Only include winuser.h in oleidl.idl as a replacement for windows.h when compiling the Wine source.
by Jacek Caban Dec. 29, 2011

Dec. 29, 2011

Hi Francois, On 12/28/11 10:39, Francois Gouget wrote: > -cpp_quote("#include<winuser.h>") > +cpp_quote("#ifdef __WINESRC__") > +cpp_quote("# include<winuser.h>") > +cpp_quote("#endif") > > /***************************************************************************** > * IOleTypes interface How about entirely removing that include? We can always include it in C files that need it. Jacek

3 2

PVS-Studio run against ReactOS: (at least) one bug in wine git
by Vincent Pelletier Dec. 28, 2011

Dec. 28, 2011

Hi. Reading this page about a PVS-Studio run against ReactOS: http://www.viva64.com/en/a/0076/ I looked up in wine's repository the ones mentioned in the article. There are more in the full output: http://www.viva64.com/external-pictures/txt/PVS-Studio-vs-ReactOS-en-unicod… I found only one error still present: strcmpW without use of return value is still present, dlls/msdmo/dmoreg.c:620 I guess wcscpy (or so) was intended. Cc'ed Ulrich Czekalla, as "git blame" brings his name up (...from 2003 !). Regards, -- Vincent Pelletier

1 0

DIB crash with gdb
by Michael Ost Dec. 28, 2011

Dec. 28, 2011

Hi, Is it possible that AddVectoredExceptionHandler doesn't work when running wine under gdb? Or maybe it doesn't work in a 32bit wine running in a 64bit system? I'm seeing a SEGV crash when running any wine program with wine 1.3.24 in gdb but not when running without the debugger. The crash is happening when writing to memory allocated by CreateDIBSection in the function create_alpha_bitmap(). The code is in user32/cursoricon.c. Here's where the crash happens, at line 791 in user32/cursoricon.c create_alpha_bitmap(): unsigned int alpha = ptr[3]; ptr[0] = ptr[0] * alpha / 255; <-- SEGV here With the debugger on, writing to ptr[0] causes the segfault. And, indeed, when I look at /proc/PID/maps for the problem address (0x350000) it is read only. Without the debugger, the memory is read-write and the calls work. WINEDEBUG=+relay,+cursor,+icon,+resource,+bitmap,+virtual,+seh shows that exceptions are used to unlock the DIB as needed. The X11DRV_DIB_FaultHandler is installed and supposed to get invoked when writing to the memory. And, without gdb running there are exceptions which leads to X11DRV_DIB_Unlock. Here's the trace: trace:cursor:create_alpha_bitmap line=790 i 0, ptr 0x350000, alpha ac trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e7ea0d8 ip=7e7ea0d8 tid=0028 trace:seh:raise_exception info[0]=00000001 trace:seh:raise_exception info[1]=00350000 trace:seh:raise_exception eax=9999cccc ebx=7e8a5e2c ecx=00000000 edx=00000067 esi=00350000 edi=000000ac trace:seh:raise_exception ebp=00000000 esp=0032f860 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010a02 trace:seh:call_vectored_handlers calling handler at 0x7e14beb0 code=c0000005 flags=0 trace:bitmap:X11DRV_DIB_Lock Locking 0x330 from thread 0028 trace:bitmap:X11DRV_DIB_Coerce AppMod requested in status InSync trace:virtual:NtProtectVirtualMemory 0xffffffff 0x350000 00000400 00000004 trace:virtual:VIRTUAL_SetProt 0x350000-0x350fff c-rw- trace:virtual:VIRTUAL_DumpView View: 0x350000 - 0x350fff (valloc) trace:virtual:VIRTUAL_DumpView 0x350000 - 0x350fff c-rw- trace:bitmap:X11DRV_DIB_DoProtectDIBSection Changed protection from 2 to 4 trace:bitmap:X11DRV_DIB_Unlock Unlocking in status AppMod trace:bitmap:X11DRV_DIB_Unlock Unlocked 0x330 trace:seh:call_vectored_handlers handler at 0x7e14beb0 returned ffffffff trace:cursor:create_alpha_bitmap 804 i 0, ptr 0x350000 That all works. But under gdb the exception handler is not called. The memory is not unlocked and the SEGV happens. This is all happening in a 64bit Fedora bit system where we have cross compiled a 32bit version of wine. Could that be an issue? Hopefully someone out there knows the answer to this readily. Thanks for your time! -- Michael Ost

4 6

Re: [PATCH 8/8 try2] jscript: Added more control flow tests
by Marvin Dec. 28, 2011

Dec. 28, 2011

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=16183 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 4/8 try2] jscript: Added bytecode version of try statement
by Marvin Dec. 28, 2011

Dec. 28, 2011

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=16182 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 8/8] jscript: Added more control flow tests
by Marvin Dec. 28, 2011

Dec. 28, 2011

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=16181 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [PATCH 4/8] jscript: Added bytecode version of try statement
by Marvin Dec. 28, 2011

Dec. 28, 2011

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=16180 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: cscript: Add forwarder to wscript
by Jacek Caban Dec. 27, 2011

Dec. 27, 2011

On 12/27/11 7:00 PM, André Hentschel wrote: > The difference between cscript and wscript is that wscipt should show a propertysheet and cscritp is console only, but our wscript doesn't show a propertysheet... It doesn't show a propertysheet yet, that's to be fixed. Forwarding one to another was always planned, but we need a way to switch modes. There is a command line switch to do it (//H:CScript and //H:WScript). AFAIR it didn't really work when I've tried it, but even if it's broken on Windows, we may still consider using it for our forwarding. Maybe just passing //B option would be good enough. Otherwise we'd need a Wine-specific way for informing wscript that it should behave like cscript. Differences are not too big, be we need a plan to address them. Jacek

1 1

Re: wininet: add a stub for DeleteWpadCacheForNetworks
by Dmitry Timoshkov Dec. 27, 2011

Dec. 27, 2011

Austin English <austinenglish(a)gmail.com> wrote: > +BOOL WINAPI DeleteWpadCacheForNetworks(int WPAD_CACHE_DELETE) Parameter name and type are completely wrong. > +{ > + FIXME(": stub\n"); > + return FALSE; > +} ... > +typedef enum{ > + WPAD_CACHE_DELETE_CURRENT = 0x0, > + WPAD_CACHE_DELETE_ALL = 0x1 > +} WPAD_CACHE_DELETE; -- Dmitry.

1 0

PLT Problems with Wine/Sparc
by André Hentschel Dec. 27, 2011

Dec. 27, 2011

Hi, thanks to Austin i could work on our sparc port and it seems i have it it a workable state, the remaining problem is that somehow the plt entry to libwine is fixed up wrong. I know most people on the list don't know much about sparc, so wild guesses are all i want. --- snip --- readelf -r: 0002c988 00003315 R_SPARC_JMP_SLOT 00000000 wine_dbg_log + 0 objdump -D: 0002c988 <wine_dbg_log(a)plt>: 2c988: 03 00 00 78 sethi %hi(0x1e000), %g1 2c98c: 30 bf ff e1 b,a 2c910 <_PROCEDURE_LINKAGE_TABLE_> 2c990: 01 00 00 00 nop gdb: 0xf66957e0 <+288>: call 0xf66a8988 <wine_dbg_log(a)plt> (gdb) printf "%08x\n", (void*)*0xf66a8988 033dfa34 (gdb) printf "%08x\n", (void*)*0xf66a898C 81c06200 (gdb) printf "%08x\n", (void*)*0xf66a8990 01000000 (gdb) --- /snip (also available as http://pastebin.com/JFN2w6q2 if bad format) --- it crashes (SIGSEGV) at wine_dbg_log(a)plt (0xf66a8988) in imm32.dll.so (if i remove the TRACE from DllMain it continues to crash with other libwine functions in winex11) 033dfa34 seems like a wrongly fixed up opcode to me. What do you guess? Should i file a bug? where? -- Best Regards, André Hentschel

2 1

NVidia Texture Tools still useful?
by Scott Ritchie Dec. 27, 2011

Dec. 27, 2011

I found this old bug report today, that I had forgotten about: https://bugs.launchpad.net/ubuntu/+bug/382512 Do we still have a use case for NVidia Texture Tools if I put these packages into the distro? Thanks, Scott Ritchie

1 0

Re: [PATCH 1/4] d3dx9/tests: Add effect parameter value GetMatrix() test.
by Marvin Dec. 26, 2011

Dec. 26, 2011

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=16158 Your paranoid android. === WVISTAADM (32 bit effect) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Re: kernel32/tests: test that GetModuleFileName returns an absolute path
by Dmitry Timoshkov Dec. 25, 2011

Dec. 25, 2011

Thomas Faber <thfabba(a)gmx.de> wrote: > diff --git a/dlls/kernel32/tests/Makefile.in b/dlls/kernel32/tests/Makefile.in > index dce27db..2ce3ec6 100644 > --- a/dlls/kernel32/tests/Makefile.in > +++ b/dlls/kernel32/tests/Makefile.in > @@ -1,5 +1,5 @@ > TESTDLL = kernel32.dll > -IMPORTS = user32 advapi32 > +IMPORTS = user32 advapi32 shlwapi Adding a shlwapi dependency to the kernel32 test suite is not a good idea, please find a way to avoid it. -- Dmitry.

2 1

Re: [PATCH RFC 5/5] dsound: convert from fixed to floating point
by Chris Robinson Dec. 25, 2011

Dec. 25, 2011

On Saturday, December 24, 2011 9:20:38 PM Alexander E. Patrakov wrote: > Andrew Eikum converted the buffer position calculation code from fixed > point to floating point, because floating-point code is more readable. > I agree with him. FWIW, I'm not sure using floating point for the position index is that good of an idea since it needs to be converted to integer all the time. Float-to-int conversions are very slow because it involves reading the FPU control word, setting a new control word with the proper rounding mode (which takes several cycles), storing the float value as an integer, then setting the old control word back (which again takes several cycles). It does this every time a float gets converted to an int, and does something similar when you truncate/floor the float value. In addition, you have potential rounding errors caused by precision loss as the exponent gets larger. Fixed-point doesn't have this issue since the precision is fixed, and the result will always be consistent. E.g., val + step*3 == val + step + step + step is true with fixed-point, but may not be true with floating-point and can result in a value that's larger or smaller than you expect. In some circumstances, it could even cause you to read past the end of the buffer. If you're concerned about cleanliness, perhaps some simple inline functions could be used to hide the bit-manipulation.

1 0

Re: [PATCH RFC 5/5] dsound: convert from fixed to floating point
by Alexander E. Patrakov Dec. 25, 2011

Dec. 25, 2011

"Alexander E. Patrakov" <patrakov(a)gmail.com> wrote: > Andrew Eikum converted the buffer position calculation code from fixed > point to floating point, because floating-point code is more readable. > I agree with him. > > I am not sending further patches out, because it is not yet clear > which of the two proposed patchsets for bug 14717 will be the final > one. Anyway, both of the approaches depend on all the patches that I > sent today. > Please ignore this patch for now, it has at least one bug. - freqAcc += adj; - adv = (freqAcc >> DSOUND_FREQSHIFT); - freqAcc &= (1 << DSOUND_FREQSHIFT) - 1; - ipos += adv * istride; + freqAcc += dsb->freqAdjust; + ipos += ((DWORD)freqAcc) * istride; + freqAcc -= truncf(freqAcc); The last line of this hunk is wrong, should be "=", not "-=". -- Alexander E. Patrakov

1 1

Status of DIB engine ?
by Massimo Del Fedele Dec. 24, 2011

Dec. 24, 2011

As I've got no idea of the status of DIB engine, besides looking at changelogs, I'd like to know it... at least to see if there's some need of help. The stuff that interests me at most is, as usual, the display speed of autocad with embedded truetype fonts (aka bug 13801), which depends deeply on DIB engine. From what I see in changelogs, text output seems to be completed; well, the speed of autocad text rendering has risen a *small* bit, but it's still unusable, light years far away from speed of my old engine which I'm still using for my job. So, the question : have I understood right from changelogs and text is completed in DIB engine, so I can help to make it a bit faster, or it's still missing something so I should just wait ? Max

2 2

Mac OS X specific bugs
by Joerg-Cyril.Hoehle＠t-systems.com Dec. 24, 2011

Dec. 24, 2011

Hi, I encourage the Mac OS X users among you to retest your apps. I have observed several bugs but have not found time to bisect them. Some of those may be old as I don't have time either to test apps regularly, i.e. with every release. o mouse issues (likely shared with XInput 2 trouble on Linux) - Black & White 2 no mouse in main menu - Two mice in Haegemonia 2 (one HW, one SW) - Second mouse at 2*x,2*y in Haegemonia 2 while pressing button o Some games from Deck13 hang at start: Luka, Ankh 1, Ankh 2 o Pirates! takes ages to start (and some other app too) o Motocross Madness 2 doesn't start nowadays IIRC o FS2002 now nearly kills the whole UI -- I had to ssh into the Mac and kill Wine. Clearly a bug in MacOS or XQuartz, however it should be possible not to trigger that bug. o Some other app (Pirates!?) also caused the wm to almost hang, reacting half a minute late to my clicks to switch to another window. Unlike FS2002, it returned to normal after the app/Wine had finished initialization. Also, there's one thing that has annoyed me for months. Since one of Damjan Jovanovic's patches, my /tmp/ directory gets spammed with .icons files, thousands of them after some time. IIRC on Linux, it's always the same .desktop files that are recreated, so it doesn't matter. I once wrote a private patch to restore Linux behavior on Mac, because I've described in the Wiki's Mac FAQ how to turn these .desktop into .command files with icons. Happy new year, Jörg Höhle

2 1

Re: gdi32: Avoid making a DBCS character in range. (try 2)
by Alexandre Julliard Dec. 23, 2011

Dec. 23, 2011

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Fixed build failure. (IsDBCSLeadByte -> IsDBCSLeadByteEx) > --- > dlls/gdi32/font.c | 14 +++++++++++--- > dlls/gdi32/tests/font.c | 30 +++++++++++++++++++++++------- > 2 files changed, 34 insertions(+), 10 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok wine: Unhandled page fault on write access to 0x00150000 at address 0x6899ab70 (thread 003e), starting debugger... err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x6834c19c make: *** [font.ok] Error 5 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcr90: Implement fread_s. (try 2)
by Piotr Caban Dec. 23, 2011

Dec. 23, 2011

On 12/23/11 08:44, Kusanagi Kouichi wrote: > + if (!buf) > + { > + _invalid_parameter(NULL, NULL, NULL, 0, 0); > + return 0; > + } You should set errno here. > + if (bufsize / size< count) > + { > + fread(buf, bufsize, 1, fp); > + if (!feof(fp)) > + { > + _invalid_parameter(NULL, NULL, NULL, 0, 0); > + memset(buf, 0, bufsize); > + fseek(fp, 1, SEEK_SET); > + } > + return 0; > + } This is still not working good. I don't know how it should be implemented without doing much more testing. Probably printing a FIXME message and returning an error will be acceptable. If you want to fully implement it I guess it should do something like this: - execute _filbuf (this is probably causing the one character position change you're observing) - analyze internal FILE buffer and return error if needed - do the read There are some problems if more data should be read then can be stored in internal FILE buffer.

2 1

Re: msvcr90: Implement fread_s. (try 2)
by Marvin Dec. 23, 2011

Dec. 23, 2011

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=16144 Your paranoid android. === WXPPROSP3 (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 7C91B21A === W2K3R2SESP2 (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 7C84CDE2 === WVISTAADM (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 7746E13D === W2K8SE (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 77883387 === W7PRO (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 772AFC47 === W7PROX64 (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 77E08C39 === TEST64_W7SP1 (32 bit msvcr90) === msvcr90: unhandled exception c0000005 at 77598DA9 === W7PROX64 (64 bit msvcr90) === Timeout === TEST64_W7SP1 (64 bit msvcr90) === Timeout

1 0

Re: [PATCH] gdi32: initialize src fully (Coverity)
by Alexandre Julliard Dec. 22, 2011

Dec. 22, 2011

Marcus Meissner <marcus(a)jet.franken.de> writes: > The .layout member is not initialized, but the whole struct > is copied to "dst", triggering an uninitialized warning. That's only hiding potential bugs. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine Gecko 1.5 delayed
by Jacek Caban Dec. 22, 2011

Dec. 22, 2011

Hi all, Earlier this week, Firefox 9 was released and Firefox 10 went to beta channel. It would usually mean that we'd have new Gecko update beta version within days. However, that would mean the final version would have be merged to Wine in 6 weeks from now, which will probably be in a middle of code freeze. With that in mind, I'm going to skip this Firefox release. The exact plan for the next update will be adjusted to come as soon as possible after Wine 1.4 release. Cheers, Jacek

1 0

Re: [2/2] msvcr90: Implement fread_s.
by Piotr Caban Dec. 22, 2011

Dec. 22, 2011

On 12/21/11 16:49, Kusanagi Kouichi wrote: > + if (bufsize / size< count) > + { > + _invalid_parameter(NULL, NULL, NULL, 0, 0); > + fseek(fp, bufsize, SEEK_CUR); It's not correct to make a seek here. The file position changes you're observing is related to data being read to FILE buffer. This is also not working in case of small file. invalid_parameter handler should only be invoked if data is to big to fit into the buffer. > + /* fread_s raises an exeption if a file was opened by fopen */ Probably you did something wrong here. It's allowed to use fread_s and fopen (unless there was a broken version of msvcrt90). > + /* fclose raises an exception if a file was opened by fopen_s */ This doesn't seem right as well. > + ret = p__fclose_nolock(file); It should be easy to add a proper implementation of _fclose_nolock. Piotr

2 2

Re: [1/2] ws2_32/tests: Test some completion port behaviour.
by Hans Leidekker Dec. 22, 2011

Dec. 22, 2011

Hi Ričardas, > + key = 0xdeadbeef; > + num_bytes = 0xdeadbeef; > + olp = (WSAOVERLAPPED *)0xdeadbeef; > + bret = GetQueuedCompletionStatus( io_port, &num_bytes, &key, &olp, 100 ); > + todo_wine ok( bret == FALSE && GetLastError() == ERROR_NETNAME_DELETED, "failed to get completion status %u\n", GetLastError() ); For tests like this you should set last error to some known value before calling the function. And it would be better to split them up; one test for the return value and one for the error. > + key = 0xdeadbeef; > + num_bytes = 0xdeadbeef; > + olp = (WSAOVERLAPPED *)0xdeadbeef; > + bret = GetQueuedCompletionStatus( io_port, &num_bytes, &key, &olp, 100 ); > + todo_wine ok(bret == FALSE && GetLastError() == ERROR_OPERATION_ABORTED, "failed to get completion status %u\n", GetLastError() ); > + todo_wine ok(key == 125, "Key is %lu\n", key); > + todo_wine ok(num_bytes == 0, "Number of bytes transfered is %u\n", num_bytes); > + todo_wine ok(olp == &ov, "Overlaped structure is at %p\n", olp); > + todo_wine ok(olp && (olp->Internal == (ULONG)STATUS_CANCELLED), "Internal status is %lx\n", olp ? olp->Internal : 0); You may want to call GetQueuedCompletionStatus again here to show that this was the last completion.

1 0