October 2007 - Wine-Devel - list.winehq.org

re: RICHED20: fix test crash on WinXP-SP2

by Dan Kegel

Alex Lasso wrote: > First of several patches to make riched20 tests actually pass on Windows. Without your patch, "make test" crashes for me on Wine. Your patch fixes the crash. So this isn't just a problem on Windows, thanks for fixing it! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Oct. 29, 2007

re: tools/widl/typegen.c pointer initialization

by Dan Kegel

Dan H. wrote: > If you tell me what options you build with and I can reproduce the > warning then I'll be more than happy to try to fix it. I build widl > with -W -Wall and get two warnings. To get uninitialized warnings, you have to also specify optimization (-O2). Without -O, gcc doesn't do the analysis that can detect uninitialized variables. - Dan

Oct. 29, 2007

Re: tools/widl/typegen.c pointer initialization

by Dan Hipschman

On Mon, Oct 29, 2007 at 01:26:45AM +0100, Gerald Pfeifer wrote: > I think the question is whether a compiler can reasonably be expected > to deduce that the source is fine. If that deduction involves solving > the halting problem (or similar) hacking the source to avoid the warning > actually doesn't occur to be that bad. ;-) Nope, you can't depend on the compiler to verify your code is correct. That's why you should try to write it in such a way that people can understand it. Hacking the code to make the compiler happy at the cost of making the code less clear is not a good idea. > > I think the real problem is that the code is just not clear enough. > > I've been meaning to add asserts. Where asserts are impractical: > > comments. > > Does this mean you are going to submit some patches to address this? If you tell me what options you build with and I can reproduce the warning then I'll be more than happy to try to fix it. I build widl with -W -Wall and get two warnings. One of which is in the bison-generated code; the other I sent a patch to silence and Alexandre rejected it.

Oct. 29, 2007

Convincing Valgrind to give a stack dump?

by Dan Kegel

Looking at the app in bug 10125, using warn+heap, I saw a few of those scary-but-sometimes-harmless warnings, so I thought I'd give it a shot under Valgrind. After applying enough suppressions, I did find three interesting valgrind warnings: 10 errors in context 5 of 9: Conditional jump or move depends on uninitialised value(s) at 0x477F7F6: RedrawWindow (painting.c:612) 29 errors in context 7 of 9: Conditional jump or move depends on uninitialised value(s) at 0x43E4E6D: HEAP_ValidateInUseArena (heap.c:917) 184 errors in context 9 of 9: Conditional jump or move depends on uninitialised value(s) at 0x61F3CD0: XcursorImageHash (in /usr/lib/libXcursor.so.1.0.2) The commandline I used was WINEDEBUG=+process valgrind -v --error-limit=no --trace-children=yes --suppressions=$HOME/suppressions ~/wine-git/wine Olb.exe (+process was used to show that the errors in question did indeed come from olb.exe and not something it launched.) But I couldn't coax Valgrind into giving stack dumps for those errors; it acted as if it had seen a few too many errors first, and only showed the one line. Grr. Anyone know how to coax valgrind into always giving a good stack dump? - Dan

Oct. 29, 2007

Re: [PATCH] Currently the serial code interprets

by Juan Lang

Hi Tom, > Content-Type: text/x-patch; name=0001-XONXOFF-reversion.patch > Content-Transfer-Encoding: base64 Apparently gmail's encoding .patch files as base64. It should be text/plain. Please try renaming it to, e.g., 0001-XONXOFF-reversion.diff and try again. --Juan

Oct. 29, 2007

Re: tools/widl/typegen.c pointer initialization

by Gerald Pfeifer

On Sun, 28 Oct 2007, Dan Hipschman wrote: > The logic is as follows: Thanks for the explanation, Dan! > Better than this would be to put "assert(is_user_type(type));" above the > initializations to convince the programmer at least that name will get > initialized correctly in get_user_type. If that doesn't convince the > compiler then I don't think it's worth it to try to placate it since > we're supposed to be wrting code for humans, not computers. I think the question is whether a compiler can reasonably be expected to deduce that the source is fine. If that deduction involves solving the halting problem (or similar) hacking the source to avoid the warning actually doesn't occur to be that bad. ;-) After the work I did again in the last weeks Wine now builds more or less without warnings for most versions of GCC (and our default set of options). If things continue to proceed well, this may be the only warning left in the whole codebase in a week or two. > I think the real problem is that the code is just not clear enough. > I've been meaning to add asserts. Where asserts are impractical: > comments. Does this mean you are going to submit some patches to address this? Gerald

Oct. 29, 2007

ATI fglrx 8.42 Driver issues

by Brian Dunne

Hello wine crew, Not sure how many of you are ATI card users, but they released a new version of their binary driver a few days ago. It provides some great performance increases in native apps like Enemy Territory: Quake Wars, but I encountered a pretty serious problem when trying to wine World of Warcraft in OpenGL mode. In short, it won't draw models - it seems to draw environments and effect animations fine, but characters and objects like benches and mailboxes are invisible. It seems the majority of the focus is on testing at this point, but if there is any additional information I can provide which would help you graphics guys (available OpenGL extensions, etc.) please let me know. It's about time I contributed something to the project. =) Thanks, Brian Dunne

Oct. 28, 2007

Re: [1/3] comctl32: Do not call parent of tool window for tip text

by Ann & Jason Edmeades

> Sending message to parent in tooltip code > probably simply works around toolbar's broken behavior. In this case I think > I've identified a line in toolbar.c that fails to properly detect empty string > causing not appearing tooltips in Radmin. I'll try to submit another patch with > this fix shortly. Thanks for checking this out - If your new patch makes tooltips work, I should probably be quiet... But.. I was looking through my notes of when I was working on this bug, looking at SPY++ logs from windows and comparing them with +spy,+message,+msg etc logs from wine. My notes indicated I was seeing the following sequence (I have hwnds or whatever spy logs written down): Tooltip sends toolbar needtextW Sends to base class tbn_GetInfoTipA which didn't return anything Sends tbn_GetInfoTipA to its parent which didn't return anything Tooltip sends baseclass ttn NeedTextA Which forwards to parent as ttn NeedTextA My notes and investigations could be wrong, does this tie up with what you were seing? Jason

Oct. 28, 2007

Pegasus Mail: program closes when sub-program closes

by Joel Barnett

Sent to bugzilla, and to this email addy, as per winehq instructions: http://www.pmail.com/downloads_maine_t.htm Version to look at is 4.41, a free download. This email app does a normal shutdown whenever the editor is closed, e.g., after a new email is sent. This is not normal behaviour. In Windows the app stays open, so that one can continue sending, receiving, reading, writing email, etc. In old versions of wine, this error doesn't happen, (ver. 20050830). The regression error occurs as early as 0.9.20. Based on posts to the wine appdb for this app, it is likely that the regression error ocurred >=0.9.14. The editor in Pmail was not written by the developer and maintainer, David Harris, but rather licensed by him. Recent wine code seems to interpret an ordinary call to close the editor as a call to close the program itself. When Pmail starts, a 0 byte file, mailbox.lck is created in the mail box of the user. When the user closes the program normally, this file is deleted. Since the shutdown regression error deletes the lock file, I conclude the call to close the editor is being misinterpreted by wine as a call to shutdown Pmail. Joel Barnett New super maintainer for Pegasus Mail p.s. - I'm new at this, please forgive me if my report is funky. I did check bugzilla and didn't find anything relevant.

Oct. 28, 2007

Re: ddraw: allow explicit backbuffer

by Jaroslav Reznik

> There is a test in the ddraw tests that shows that this is not allowed. This > test will break I guess. > > However, maybe it is a version differece. The test tests IDirectDraw7 I think, > maybe the game uses an older version. > It looks like DirectX 6.0 and above game (requirement in their web) but this is quite new version. It is very popular in Czech and general rating of quality of Wine for many Czech users :) It's free game, you can download it here http://download.sleepteam.com/bulanci.exe - Czech version called Bulanci. Jaroslav Reznik

Oct. 28, 2007