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

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