- wine-devel - winehq.org

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

29 Dec '11

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 28 Dec '11

28 Dec '11

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 28 Dec '11

28 Dec '11

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 28 Dec '11

28 Dec '11

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 28 Dec '11

28 Dec '11

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 28 Dec '11

28 Dec '11

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 28 Dec '11

28 Dec '11

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 27 Dec '11

27 Dec '11

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 27 Dec '11

27 Dec '11

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 27 Dec '11

27 Dec '11

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@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@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@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 27 Dec '11

27 Dec '11

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 26 Dec '11

26 Dec '11

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 25 Dec '11

25 Dec '11

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 25 Dec '11

25 Dec '11

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 25 Dec '11

25 Dec '11

"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 24 Dec '11

24 Dec '11

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 24 Dec '11

24 Dec '11

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 23 Dec '11

23 Dec '11

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 23 Dec '11

23 Dec '11

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 23 Dec '11

23 Dec '11

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 22 Dec '11

22 Dec '11

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 22 Dec '11

22 Dec '11

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 22 Dec '11

22 Dec '11

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 22 Dec '11

22 Dec '11

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

Re: [PATCH] comdlg32: Correctly handle filters with multiple file extensions in Save As dialogs (try 3)
by Marvin 20 Dec '11

20 Dec '11

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=16077 Your paranoid android. === TEST64_W7SP1 (32 bit filedlg) === filedlg: unhandled exception c0000005 at 75AF1AC3

2 1

Re: [PATCH] comdlg32: Correctly handle filters with multiple file extensions in Save As dialogs (try 2)
by Marvin 20 Dec '11

20 Dec '11

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=16065 Your paranoid android. === WVISTAADM (32 bit filedlg) === Timeout === W2K8SE (32 bit filedlg) === Timeout === W7PRO (32 bit filedlg) === filedlg.c:1060: Test failed: TestFilter (*.pt*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.pt*;*.abc): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.ab?): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.ab?): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: (null): expected TRUE filedlg.c:1066: Test failed: (null): Filename is deadbeef, expected deadbeef.xy* === W7PROX64 (32 bit filedlg) === filedlg.c:1060: Test failed: TestFilter (*.pt*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.pt*;*.abc): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.ab?): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.ab?): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: (null): expected TRUE filedlg.c:1066: Test failed: (null): Filename is deadbeef, expected deadbeef.xy* === TEST64_W7SP1 (32 bit filedlg) === filedlg.c:1060: Test failed: TestFilter (*.pt*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.pt*;*.abc): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.ab?): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.ab?): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: (null): expected TRUE filedlg.c:1066: Test failed: (null): Filename is deadbeef, expected deadbeef.xy* === W7PROX64 (64 bit filedlg) === filedlg.c:1060: Test failed: TestFilter (*.pt*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.pt*;*.abc): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.ab?): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.ab?): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: (null): expected TRUE filedlg.c:1066: Test failed: (null): Filename is deadbeef, expected deadbeef.xy* === TEST64_W7SP1 (64 bit filedlg) === filedlg.c:1060: Test failed: TestFilter (*.pt*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.pt*;*.abc): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.ab?): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.ab?): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: TestFilter (*.*): expected TRUE filedlg.c:1066: Test failed: TestFilter (*.*): Filename is deadbeef, expected deadbeef.xy* filedlg.c:1060: Test failed: (null): expected TRUE filedlg.c:1066: Test failed: (null): Filename is deadbeef, expected deadbeef.xy*

1 0

Re: secur32/tests: Fail on missing NTLM
by Marvin 19 Dec '11

19 Dec '11

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=16052 Your paranoid android. === WNT4WSSP6 (32 bit ntlm) === ntlm.c:1231: Test failed: AcquireCredentialsHande() returned SEC_E_INVALID_TOKEN ntlm.c:423: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:433: Test failed: expected SEC_E_INTERNAL_ERROR or SEC_I_CONTINUE_NEEDED, got SEC_E_NO_IMPERSONATION ntlm.c:445: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:457: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:885: Test failed: cbSecurityTrailer should be 16 but is 0 ntlm.c:423: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:433: Test failed: expected SEC_E_INTERNAL_ERROR or SEC_I_CONTINUE_NEEDED, got SEC_E_NO_IMPERSONATION ntlm.c:445: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:457: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:885: Test failed: cbSecurityTrailer should be 16 but is 0 ntlm.c:423: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:433: Test failed: expected SEC_E_INTERNAL_ERROR or SEC_I_CONTINUE_NEEDED, got SEC_E_NO_IMPERSONATION ntlm.c:445: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:457: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:885: Test failed: cbSecurityTrailer should be 16 but is 0 ntlm.c:423: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:433: Test failed: expected SEC_E_INTERNAL_ERROR or SEC_I_CONTINUE_NEEDED, got SEC_E_NO_IMPERSONATION ntlm.c:445: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:457: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:885: Test failed: cbSecurityTrailer should be 16 but is 0 ntlm.c:423: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:433: Test failed: expected SEC_E_INTERNAL_ERROR or SEC_I_CONTINUE_NEEDED, got SEC_E_NO_IMPERSONATION ntlm.c:445: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:457: Test failed: expected SEC_E_BUFFER_TOO_SMALL, got SEC_E_INSUFFICIENT_MEMORY ntlm.c:1031: Test failed: MakeSignature returned SEC_E_INVALID_TOKEN, not SEC_E_OK. ntlm.c:1061: Test failed: Crypt trailer not as expected. ntlm.c:1075: Test failed: Crypt message not as expected. ntlm.c:1097: Test failed: DecryptMessage returned SEC_E_MESSAGE_ALTERED, not SEC_E_OK. ntlm.c:1099: Test failed: Failed to decrypt message correctly. ntlm.c:1127: Test failed: MakeSignature returned SEC_E_INVALID_TOKEN, not SEC_E_OK. ntlm.c:1135: Test failed: VerifySignature returned SEC_E_INVALID_TOKEN, not SEC_E_OK ntlm.c:1139: Test failed: EncryptMessage returned SEC_E_INVALID_TOKEN, not SEC_E_OK. ntlm.c:1157: Test failed: Crypt message not as expected. ntlm.c:1176: Test failed: DecryptMessage returned SEC_E_INVALID_TOKEN, not SEC_E_OK.

1 0

[PATCH 1/4] mmdevapi: Enforce limits on period and duration.
by Joerg-Cyril.Hoehle＠t-systems.com 19 Dec '11

19 Dec '11

Hi, the patch catches shared mode very well, however it appears that exclusive mode exhibits vastly different behavior from one machine to the next. As WASAPI is MS' low(est)-level audio API, the observable behavior appears to really depend on the individual HW drivers. Examples: The 8x multiplier is observable with testbot. One particular native w7 native machine (no vmware) does not know that multiplier and is clamping to max 32768 frames instead. That machine seems to use 1024 frames as multiplier for buffer size, i.e. 21.333ms -- which reminds me of ALSA's dmix. Furthermore, its GetCurrentPadding seems to return continuous values. GetPosition follows GCP (like winecoreaudio.drv now does), whereas (several VMs on) testbot exhibit period-sized deltas in GCP -- like in shared mode. IOW, exclusive mode shows quite a range of different behaviours. Wine just has to choose one. Regards, Jörg Höhle

1 0

Re: [2/2] ws2_32/tests: Add a test to show what happens when the listen socket is closed after an AcceptEx call.
by Marvin 19 Dec '11

19 Dec '11

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=16049 Your paranoid android. === W2KPROSP4 (32 bit sock) === sock: unhandled exception c0000005 at 05280023

1 0

Re: [PATCH 2/6] jscript: Use bytecode for block statement implementation
by Marvin 19 Dec '11

19 Dec '11

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=16041 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 1/5] ddraw/tests: Introduce some functions for comparing floating-point vectors.
by Henri Verbeet 19 Dec '11

19 Dec '11

On 19 December 2011 13:37, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > + /* The coordinates are all offset by about (1e-6, 1e-6) for some reason. > + * On the y-axis we apparently have somewhat less precision, and the > + * offset gets lost for viewports more than 31 high. */ Except when it doesn't. I'll resend this with a viewport that isn't as sensitive to this.

1 0

Re: [PATCH 3/5] ddraw/tests: Introduce proper vector types.
by Marvin 19 Dec '11

19 Dec '11

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=16036 Your paranoid android. === W2KPROSP4 (32 bit d3d) === d3d.c:559: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === W2K3R2SESP2 (32 bit d3d) === d3d.c:559: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === W2K8SE (32 bit d3d) === d3d.c:559: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === W7PROX64 (32 bit d3d) === d3d.c:559: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === TEST64_W7SP1 (32 bit d3d) === d3d.c:559: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}.

1 0

Re: [PATCH 2/5] ddraw/tests: Remove a redundant IDirect3DDevice7_SetViewport() call.
by Marvin 19 Dec '11

19 Dec '11

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=16035 Your paranoid android. === W2KPROSP4 (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === W2K3R2SESP2 (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === W2K8SE (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === W7PROX64 (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === TEST64_W7SP1 (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}.

1 0

Re: [PATCH 1/5] ddraw/tests: Introduce some functions for comparing floating-point vectors.
by Marvin 19 Dec '11

19 Dec '11

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=16034 Your paranoid android. === W2KPROSP4 (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === W2K3R2SESP2 (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === W2K8SE (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === W7PROX64 (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}. === TEST64_W7SP1 (32 bit d3d) === d3d.c:560: Test failed: Got unexpected vertex 1 {2.55999985e+002, 1.52587891e-005, 9.99999940e-001, 9.99999940e-001}.

1 0

Re: [1/6]usp10: code for the cmap format 12 table for unicode code points beyond the BMP
by Alexandre Julliard 19 Dec '11

19 Dec '11

Aric Stewart <aric(a)codeweavers.com> writes: > + while (k < GET_BE_DWORD(format->nGroups)) > + { > + if (GET_BE_DWORD(format->groups[k].startCharCode) > utf32c) > + break; > + if (GET_BE_DWORD(format->groups[k].endCharCode) < utf32c) > + k++; > + else > + { > + DWORD offset = utf32c - GET_BE_DWORD(format->groups[k].startCharCode); > + *pgi = GET_BE_DWORD(format->groups[k].startGlyphID) + offset; > + return 0; > + } You probably want a binary search. Also do we really need a new source file for such a small function? -- Alexandre Julliard julliard(a)winehq.org

1 0

Looking to implement msvcp90's basic_ifstream (and friends)
by Aaron Faanes 19 Dec '11

19 Dec '11

Howdy! I ran into this bug when running a game of mine, and it seemed doable for me. The bug is due to msvcp90 missing its file I/O stuff. Here's the link: http://bugs.winehq.org/show_bug.cgi?id=25966 My intention is to implement these classes as wrappers of ntdll's file I/O API. Is this the right approach, or is there another API that is more preferable? -- Aaron Faanes <dafrito(a)gmail.com>

2 5

Re: [PATCH] comdlg32: Correctly handle filters with multiple file extensions in Save As dialogs
by Marvin 19 Dec '11

19 Dec '11

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=16032 Your paranoid android. === WNT4WSSP6 (32 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === W2KPROSP4 (32 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in est\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in est\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in est\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === WXPPROSP3 (32 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in est\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in est\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in est\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === W2K3R2SESP2 (32 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in est\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in est\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in est\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === WVISTAADM (32 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === W2K8SE (32 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === W7PRO (32 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === W7PROX64 (32 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === TEST64_W7SP1 (32 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === W7PROX64 (64 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)" === TEST64_W7SP1 (64 bit filedlg) === filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;)" filedlg.c:1106: Test failed: Filename ends in m32\deadbeef, expected deadbeef.abc from filter "TestFilter (*.abc;*.def)"

1 0

Re: wineconsole: Remove the character-width check as we need newer FreeType library.
by Eric Pouech 18 Dec '11

18 Dec '11

this doesn't solve the printing issue as the always infer that any char has the same size how is this printed on real windows with your character set ? A+ 2011/12/14 Akihiro Sagawa <sagawa.aki(a)gmail.com> > > This closes bug #10063. This check is needed for FreeType < 2.0.8, but > commit 570e68b82200bdd9981b2cd8fe9e68d35bad3cb9 updated the requirement, > 2.1.4 or later. And it is not useful for DBCS fonts, as they have two > different width (halfwidth and fullwidth) even in monospaced font such > as MS Gothic. > --- > programs/wineconsole/user.c | 34 ++-------------------------------- > 1 files changed, 2 insertions(+), 32 deletions(-) > > > > > -- -- Eric Pouech

2 2

Warning report for wine-1.3.35
by Jerome Leclanche 18 Dec '11

18 Dec '11

No more warnings on 32-bit :) I'm still getting "warning: variable ‘_qzz_res’ set but not used" from valgrind though (stripped from the report); does anyone know what's up with those? J. Leclanche

1 0

Debugging Wine with Lightroom 3.5
by Roland Baudin 17 Dec '11

17 Dec '11

Hi, let me first congratulate all the people who work hard on the Wine project : their work is much appreciated here... Now, my question : I was able to install and run Adobe Photoshop Lightroom 3.5 under wine 1.3.33 or 1.3.34. While it runs quite well and is fairly stable I have two major issues : - with Windows version set in winecfg to "Windows XP" (or below) the menu bar is hidden. However, clicking on the empty place of the menu bar partially reveals the menu items and they are functional. Moreover, other context menus (for example, right clicking on a picture and selecting Delete brings up the deletion dialog) are all working OK. - with Windows version set in winecfg to "Vista" (or higher) the menu bar is now visible and fully functional, but many context menus are not working anymore (for example, right clicking on a picture and selecting Delete does nothing now). [Note this problem is half known (see bug 18635 http://bugs.winehq.org/show_bug.cgi?id=18635).] So the dilemma is : either set Windows version to XP and get fully functional context menu but a hidden menu bar, or set version to Vista and see the menu bar but get many context menus broken. I'd like to debug this situation so it would be nice if someone could point me to the right direction : - first I don't understand the relation between Windows versions and menu bar or dialogs. Is it related to different versions of the dlls or any other mechanism? - second, I noticed with XP version a lot of fixme:GetMenuInfo when running Lightroom. These messages don't appear with Vista version. I've tried to set up a patch (found on the Internet) that implement the GetMenuInfo function but this doesn't help. The patch seems to work but the menu bar is still hidden. - third, with Vista version, when invoking a broken menu, there is no particular message I can see on the terminal that could tell me what is not working. I've tried to play with various dll replacement but with no success. After googling and reading I suspect the problem is in the user32.dll and perhaps the DrawMenuBar implementation but I'm not sure... Any help (at least some clue to start debugging) would be greatly appreciated. Thanks, RB -- X File Explorer http://roland65.free.fr/xfe Toutes Choses http://roland65.free.fr/ttc

2 1

Would making the Wine file dialogs know about the Nautilus bookmarks be a reasonable thing?
by Scott Ritchie 17 Dec '11

17 Dec '11

Assuming you're running Gnome, as I'm not sure there's a freedesktop standard for the Bookmark feature yet (and perhaps there should be). In every Gnome nautilus window, save dialog, and file open dialog there's a standard set of folders you see on the side as quick links. Some are obvious, and we duplicate them (eg Desktop), others are automatic, like gvfs links to external hard disks. Users can also add their own. Would it be appropriate to display those self-added bookmarks in Wine? I'm worried there might be something I'm missing about the implementation that would make this difficult or a bad idea. Thanks, Scott Ritchie

4 3

Re: [PATCH 2/2] comdlg32: Widen buffer to accomodate Catalan translation
by Francois Gouget 17 Dec '11

17 Dec '11

On Fri, 16 Dec 2011, Alex Henrie wrote: > --- > dlls/comdlg32/filedlg.c | 2 +- [...] > - WCHAR buf[16]; > + WCHAR buf[17]; > LoadStringW(COMDLG32_hInstance, IDS_SAVE_AS, buf, sizeof(buf)/sizeof(WCHAR)); I don't think it makes sense to add room for just one more WCHAR. There's no telling how long a future Arabic or Panjabi translation might be. So either set the buffer size to something like 80, 128 or 256 characters (sucks 5, 8 and 16 times less respectively), or do away with the hardcoded buffer size altogether (overkill? rocks? both?<g>). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

2 1

Re: [6/6]usp10: add Mathematical Alphanumeric Symbols script
by Marvin 16 Dec '11

16 Dec '11

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=16023 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:532: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:533: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:534: Test failed: 0:Incorrect Script Tag 0 != 6874616d usp10.c:586: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:587: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:588: Test failed: 0:Incorrect Script Tag 0 != 6874616d usp10.c:640: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:641: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:642: Test failed: 0:Incorrect Script Tag 0 != 6874616d usp10.c:695: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:696: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:697: Test failed: 0:Incorrect Script Tag 0 != 6874616d === W2K8SE (32 bit usp10) === usp10.c:532: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:533: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:534: Test failed: 0:Incorrect Script Tag 0 != 6874616d usp10.c:586: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:587: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:588: Test failed: 0:Incorrect Script Tag 0 != 6874616d usp10.c:640: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:641: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:642: Test failed: 0:Incorrect Script Tag 0 != 6874616d usp10.c:695: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:696: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:697: Test failed: 0:Incorrect Script Tag 0 != 6874616d

1 0

About release 1.3.35
by GOUJON Alexandre 16 Dec '11

16 Dec '11

Am I the only one who noticed that the "Release 1.3.35" was authored by Frédéric Delanoy ? Who's the author (really) doesn't matter but having a commit from a gmail.com e-mail address instead of a winehq.org one (just) surprised me. Anyway, let's pull this latest wine version, compile and test it !

2 1

Re: [5/6]usp10: add Osmanya script
by Marvin 16 Dec '11

16 Dec '11

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=16022 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:526: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:527: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:579: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:580: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:632: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:633: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:686: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:687: Test failed: 0:Incorrect Script Tag 0 != 616d736f === W2K8SE (32 bit usp10) === usp10.c:526: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:527: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:579: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:580: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:632: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:633: Test failed: 0:Incorrect Script Tag 0 != 616d736f usp10.c:686: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:687: Test failed: 0:Incorrect Script Tag 0 != 616d736f

1 0

Re: [4/6]usp10: add Deseret script
by Marvin 16 Dec '11

16 Dec '11

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=16021 Your paranoid android. === WVISTAADM (32 bit usp10) === usp10.c:520: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:572: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:624: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:677: Test failed: 0:Incorrect Script Tag 0 != 74727364 === W2K8SE (32 bit usp10) === usp10.c:520: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:572: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:624: Test failed: 0:Incorrect Script Tag 0 != 74727364 usp10.c:677: Test failed: 0:Incorrect Script Tag 0 != 74727364

1 0

Major mmdevapi and winmm audio bugs
by Joerg-Cyril.Hoehle＠t-systems.com 16 Dec '11

16 Dec '11

Hi, The present list is quite different from what I posted 2 month ago. http://www.winehq.org/pipermail/wine-devel/2011-October/092716.html #28723 is about handling tight timing and little prefill #27901 is about snd_pcm_drop erroneously being used by AudioClient_Stop. I've a patch in my queue but it depends on the "small buffer" patch discussed in #28723. #29056 #29299 are the major "ALSA won't start without period-size frames" issue That can cause any affected app to hang. #29305 one winmm device seems to stomp over the data of another one # OSS needs to be updated to be on par with ALSA refinements #28093 MacOS GetCurrentPadding #28039 MacOS GetPosition (neeed to recheck) #28388 Avoid SuspendThread, should be easy for me to fix, given time There are QA issues not associated with a bug entry: - Add run-time consistency checks in renderer and abort audio stream (GetData) upon trouble instead of hanging. - OSS GetPosition from DSP_GETODELAY - ALSA+OSS: ReleaseBuffer: enforce method ordering and max size like CoreAudio - wineoss GetStreamLatency must be constant, and SNDCTL_DSP_GETODELAY is only usable once running - Investigate OSS4 underrun behaviour - Check WHDR_BEGIN/ENDLOOP code and write tests and finally: - Test compatibility with native DSound and file bug if unusable. There are several reports in bugzilla mentioning that this work-around ceased to work since 1.3.25. Loss of interoperability is not acceptable. Of course there are more bugs than this. Regards, Jörg Höhle

2 1

Re: [PATCH] wined3d: Fixes some windows to receive mouse clicks
by Henri Verbeet 16 Dec '11

16 Dec '11

On 14 December 2011 23:45, <qwerty0987654321(a)mail.ru> wrote: > @@ -871,6 +871,13 @@ static HRESULT swapchain_init(struct wined3d_swapchain *swapchain, WINED3DSURFTY > swapchain->win_handle = window; > swapchain->device_window = window; > > + if (!desc->windowed && window) > + { > + wined3d_device_setup_fullscreen_window(device,window, > + desc->backbuffer_width, > + desc->backbuffer_height); > + } > + I don't think that's even close to a proper fix. Regardless, any patch touching this part of the code should come with a test.

1 0

Re: crypt32: Avoid reading unitialized variables (Coverity)
by Michael Curran 16 Dec '11

16 Dec '11

2011/12/13 Frédéric Delanoy <frederic.delanoy(a)gmail.com>: > CID 4647-4648 > --- > dlls/crypt32/cert.c | 2 +- > dlls/crypt32/encode.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/crypt32/cert.c b/dlls/crypt32/cert.c > index 63107e1..ee96abd 100644 > --- a/dlls/crypt32/cert.c > +++ b/dlls/crypt32/cert.c > @@ -2554,7 +2554,7 @@ BOOL WINAPI CertAddEnhancedKeyUsageIdentifier(PCCERT_CONTEXT pCertContext, > LPCSTR pszUsageIdentifier) > { > BOOL ret; > - DWORD size; > + DWORD size = 0; > > TRACE("(%p, %s)\n", pCertContext, debugstr_a(pszUsageIdentifier)); > > diff --git a/dlls/crypt32/encode.c b/dlls/crypt32/encode.c > index 05a3558..143ef0a 100644 > --- a/dlls/crypt32/encode.c > +++ b/dlls/crypt32/encode.c > @@ -768,7 +768,7 @@ static BOOL WINAPI CRYPT_AsnEncodeExtensions(DWORD dwCertEncodingType, > ret = TRUE; > for (i = 0, dataLen = 0; ret && i < exts->cExtension; i++) > { > - DWORD size; > + DWORD size = 0; > > ret = CRYPT_AsnEncodeExtension(&exts->rgExtension[i], NULL, &size); > if (ret) > -- > 1.7.8 > > > Just a quick check, since Debian had a big kerfuffle when someone went and initialized variables in a crypto module, but is there any chance that those variables were left uninitialized on purpose?

4 8

Re: [PATCH 2/2] comdlg32: Widen buffer to accomodate Catalan translation
by Paul Chitescu 16 Dec '11

16 Dec '11

On Friday 16 December 2011 09:48:01 am Alex Henrie wrote: > --- > dlls/comdlg32/filedlg.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/comdlg32/filedlg.c b/dlls/comdlg32/filedlg.c > index 5f80519..8637944 100644 > --- a/dlls/comdlg32/filedlg.c > +++ b/dlls/comdlg32/filedlg.c > @@ -1504,7 +1504,7 @@ static LRESULT FILEDLG95_InitControls(HWND hwnd) > } > else if (fodInfos->DlgInfos.dwDlgProp & FODPROP_SAVEDLG) > { > - WCHAR buf[16]; > + WCHAR buf[17]; > LoadStringW(COMDLG32_hInstance, IDS_SAVE_AS, buf, > sizeof(buf)/sizeof(WCHAR)); SetWindowTextW(hwnd, buf); > } Don't be so cheap, if you had problems other languages my have problems as well. Make it a little larger than absolute minimum, let's say 20. Besides, the memory is allocated or aligned at at least 32 bits boundaries so a 17 or 18 WCHAR buffer will use the same amount of memory. Paul

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel