June 2004 - Wine-Devel - list.winehq.org

Re: winedbg crashes

by Eric Pouech

Jon Griffiths a écrit : > The 'read access to 0x00000001' exception is my app, but the the > debugger fails the above assertion and dies. > > I have stripped the application and .so's for this app (its winelib > based), but this doesn't help the crash. there seem to be some bugs in the stabs parsing code. Could you rerun with WINEDEBUG="+dbghelp,+dbghelp_stabs" and send me the output ? TIA

June 24, 2004

strace log of SIGSEGV on FC2

by Vincent Béron

Here's a strace log of strace ./wine in the root of a current cvs build tree, with wine's preloader debug enabled. It ends with a SIGSEGV. Vincent

June 24, 2004

FW: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier

by Krishna Murthy

Alexandre, Is these changes looks good? Do I have to submit this patch to 'wine-patches(a)winehq.org' ? Thanks, Krishna -----Original Message----- From: Krishna Murthy Sent: Tuesday, June 22, 2004 2:56 PM To: 'Alexandre Julliard'; Krishna Murthy Cc: wine-devel(a)winehq.org Subject: RE: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Alexandre, Please find attached modified patch. The method DEFDLG_SetDefButton() now accepts the BOOL bSetDefID parameter to adapt for both DM_SETDEFID and WM_NEXTDLGCTL. Thanks, Krishna -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Friday, June 18, 2004 10:30 AM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > No, it is required. The DEFDLG_SetDefButton() is also called from > message DM_SETDEFID. In this case idResult should set to the default > button ID passed. And the current logic of DEFDLG_SetDefButton() does > what is required for DM_SETDEFID. Well, of course you'd need to adapt the DM_SETDEFID handling to the change. I think that's better than sending duplicate messages. -- Alexandre Julliard julliard(a)winehq.org

June 24, 2004

Re: Free application with menu redrawing/flicker loop (window position mismatch?)

by Mike Hearn

On Thu, 24 Jun 2004 17:13:40 +0200, Andreas Mohr wrote: > If someone more familiar with messaging and window management could have a > look at it, then I'm sure he'd greatly appreciate it. :) This sounds a LOT like a problem me and Dmitry were looking at a few weeks ago. Does it work if you run the app in desktop mode? thanks -mike

June 24, 2004

Re: [WineHQ] Updated TODO

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > Can I double check that this is actually all there is to it? My reading > of the changelog was that this is only the calculations have been moved > into the server, but the rest of it has not been. For instance, I > haven't checked but it didn't look like InvalidateRect was rewritten. No, I only moved the visible region, not the update region. That one will be a lot more work. -- Alexandre Julliard julliard(a)winehq.org

June 24, 2004

Free application with menu redrawing/flicker loop (window position mismatch?)

by Andreas Mohr

Hi all, greetings from the Wine booth at LinuxTag! :) (Uwe Bonnes and me are there) The following program which a school employee (4000 pupils!) asked me about that prevents his school administration from switching to Linux has problems with continuous redrawing of the menu bar and non-redrawing of the client area (resulting from continuous menu redrawing?): http://schulverwaltungsprogramme.mswwf.nrw.de/mswf_software/html/winplan.ht… Note that installation runs fine; it's the main program which breaks. The relay log shows signs of a WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED loop or something like that. If someone more familiar with messaging and window management could have a look at it, then I'm sure he'd greatly appreciate it. :) Greetings, Andreas Mohr

June 24, 2004

Re: [WineHQ] Updated TODO

by Mike Hearn

Can I double check that this is actually all there is to it? My reading of the changelog was that this is only the calculations have been moved into the server, but the rest of it has not been. For instance, I haven't checked but it didn't look like InvalidateRect was rewritten. If this is it then I'll resend my LockWindow patch but I think there is more to come ... Alexandre? On Thu, 2004-06-24 at 09:37 -0400, Dimitrie O. Paun wrote: > ChangeLog > Alexander finished moving the visible region handling > to the server. >

June 24, 2004

Re: lost vertical and horizontal scroll bar

by Nicolai Kuntze

I have assigned this problem as bug 2302 as it was not solveable through simple dll-replacements or other configurations. Yours Nicolai Am 19.06.2004 um 21:09 schrieb hatky: > On Friday 18 June 2004 11:10, Nicolai Kuntze wrote: >> Hi, >> >> I have here an application (bmed) but I can't see any scrollbars. Is >> there something I can do? >> > try wine-users(a)winehq.org > > -- > Hatky, > Worshiper of wine (http://www.winehq.org/) > Impossible is only an opinion. > ---- Diese Nachricht wurde auf Viren und andere gefaehrliche Inhalte sowie Spam untersucht.

June 24, 2004

Re: LISTBOX_Directory() returns LB_OKAY for invalid directory / f ilen ame

by Alexandre Julliard

Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > It looks like in bug 1435 they wanted to avoid triggering of error if no > more files found. But could not understand why they wanted to avoid > triggering of error when the specified filename does not exists. In MS > windows if File Not found, then it returns error. So we could satisfy both > by just doing the following check: > >> if (le != ERROR_NO_MORE_FILES) return LB_ERR; > > So the above condition triggers error for all the error conditions except > for ERROR_NO_MORE_FILES. Which is exactly what the code looked like before the fix for bug 1435, so you will just reintroduce the bug. This needs more investigating... -- Alexandre Julliard julliard(a)winehq.org

June 23, 2004

Re: MSVCRT - __unDNameEx

by Eric Pouech

Andrei Barbu a écrit : > Hey, > > I encountered an app that heavily relies on __unDNameEx which is a stub, > and I couldn't find any MSDN info on it. > > The stub did have a hint as to an implementation of it, said that it's > been implemented pretty well in tools/winebuild/msmangle.c I looked for > that, couldn't find it, but I did find it in the CVS attic in > wine/tools/speckmaker > > http://cvs.winehq.com/cvsweb/~checkout~/wine/tools/specmaker/Attic/msmangle… > > Is there a reason this isn't used there? or can I clean it up a little > and include it? Yes it does have some fixme's, but it's better than > ignoring it. > > > > Thanks, > Andrei the winedump implementation of demangling is rather buggy (and it isn't actually fully demangling, it's spitting out C raw equivalents to the C++ methods). I'm working on a better implementation that should be available rather soon. A+

June 23, 2004