wine-devel

wine-devel@winehq.org

3 participants
84472 discussions

RE: Any advice on how to debug this?
by Medland, Bill 10 Jul '02

10 Jul '02

> -----Original Message----- > From: Eric Pouech [mailto:eric.pouech@wanadoo.fr] > Sent: Wednesday, July 10, 2002 4:59 AM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: Any advice on how to debug this? > > > > The stack traces in both cases are similar and indicate to > me that the > > processes have ended up executing data. > > However by the time I get to disassemble the code referred to by the > > backtrace the code isn't there any longer. > is most of the cases, it means that the program is no longer > running (it > may > have been killed by the other program) > > > What's my best bet for tracking this down? > as the processes seem to be furtive, using relay traces (and friends) > may be > a better bet to locate the issue, and then perhaps set the bp where > needed > > A+ > Thanks Eric. So now what do we do. Having messed about, got a repeatable case and generally bashed my head around I have got to the following unfortunate situation. It looks to me like: comctl32.dll includes a shared data segment. One of the entries in that segment, presumably during the DllEntry, is populated with the address of GetSystemMetrics A second copy of comctl32 then tries to use that address to call GetSystemMetrics Unfortunately the second process has user32 mapped somewhere else and so the call goes somewhere weird and things fall over. Any ideas as to what we can do about it? Bill

2 1

Meta-bug conversions
by Francois Gouget 10 Jul '02

10 Jul '02

Hi, I propose to use what would hopefully be better concepts to replace the following meta-bugs: * bug 35 - Wine 0.9.0 Meta Bug http://bugs.winehq.com/showdependencytree.cgi?id=35 Instead we could tag all the bug that should be fixed in Wine 0.9.0 with the 0.9.0 target milestone. * bug 395 - Tasklist http://bugs.winehq.com/showdependencytree.cgi?id=395 * bug 455 - FIXMEs http://bugs.winehq.com/showdependencytree.cgi?id=455 * bug 406- Tasklets http://bugs.winehq.com/showdependencytree.cgi?id=406 These three could be replaced by keywords: Tasklist, FIXMEs and Tasklets. Then these bugs can be replaced with a query that returns the bugs that have these keywords. In all cases, the advantages of the alternative methods are: * the above meta-bugs introduce artificial dependencies between bugs * each time a bug changes status, you get an email for the bug, and an email for the corresponding meta-bug * similarly, moving a bug moving from one category to another generates three emails * the new concepts seem a better match Does the above proposal look ok? If so then, once the required keywords are created, I can tag the relevant bugs and retire the meta-bugs (which will create a flurry of emails to wine-bugs in the short term). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

2 1

about XIM support on wine
by rain shaw 10 Jul '02

10 Jul '02

Hi all, I do apply some patches to the wine source according to some tips in bugs library,and I can input chinese in notepad now. But,every time window was created,will the input method popup.For example,if a message box popped up,the xim will popup as well. It seems that we called the XIM related Xlib function every time new window was created. Would u please give me some suggestions about how to disable create and open XIM while create non-text-input related window? in other word,how to determin the x-window that going to be created is a control that need input method ? Thanx!

2 1

Debugger
by Massimo 10 Jul '02

10 Jul '02

Hmmm.... I fiddled a bit with winedbg and found it awful to use.... Maybe I'm too comfortable with visual debuggers :-) There's no plan to make a graphical front-end to it, for example extending DDD or better GVD ? I had a look at GVD sources and docs, and it shouldn't be too difficult to add a supported debugger... It has a quite good support for many external debuggers.... I see only une problem on it, as it seems to me that winedbg opens a new xterm and translates his i/o on it, which can confuse GVD as stated in docs. So, 2 questions : 1) - There's a way to instruct winedbg to not change xterm ? 2) - There's a volunteer with enough skills on winedbg that can help me to write GVD patch ? :-) Regards Max

4 8

Problems with VGA PLANETS 4
by Oliver Ob 10 Jul '02

10 Jul '02

My P4_BUG.log 01 _ Installed Wine run with -v gives "Wine release 20000430" and error "fixme: pthread_atfork" 02 _ Edited /etc/wine.conf c:\windows\Profiles\Administrator\user.dat must be c:\windows\user.dat 03 _ Trying wine /wine/mnt/c/Programme/Play/vgap/Planets4/planets4.exe as "user" gives errors: - fixme: pthread_atfork - what does this mean at all? - fixme:reg:_w95_parse_dkv RegSetValueEx returned: 0x0000000e - err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x401 36fb4 04 _ Building the font metrics takes a LOT of time, god is that slow! And then it fails! fixme:debug:FlushInstructionCache (0xffffffff,0x41410000,0x00006000):stub last address with 6000, 6000 and with a000 - a popup window from wine says "Unhandled exception 0xc0000005 at address 0x24748b56. Do you want to debug it?" and clicking YES results in - err:seh:UnhandledExceptionFilter Couln't start debugger (winedbg 136366288 1414155735) 05 _ The Temporary Directory (as specified in your config file) is NOT writeable - how can "user" have write access to c:\temp now? What user group has rw access to /mnt/c ? 06 _ Running using su -c "see above" works better, so the errors which do not tell me nothing seem to mostly have to do with access rights. Can someone explain those errors to me? Errors are yet some others - fixme:file:AreFileApisANSI (void): stub - fixme:win32:PE_LoadImage We need to perform base relocations for c:\Programme\Play\vgap\Planets4\gug32.dll - fixme:win32:PE_CreateModule Security directory ignored - err:menu:MENU_GetMenu invalid menu handle=0, ptr(nil), magic=0 - err:menu:MENU_GetMenu invalid menu handle=0, ptr(nil), magic=0 - err:menu:MENU_GetMenu invalid menu handle=4d0, ptr=0x4043f27c, magic=0 - err:menu:MENU_GetMenu invalid menu handle=0, ptr(nil), magic=0 - err:menu:MENU_GetMenu invalid menu handle=0, ptr(nil), magic=0 - fixme:bitmap:X11DRV_DIB_GetImageBits_4 from 24 bit bitmap with mask R,G,B 0,0,0 to 4 bit DIB 07 _ Will try to make my first turn using wine + P4 now. Unpacking the RST works. It opens. I can edit the turn. Try to make a TRN file. But now this makes me worry!!!! A popup window speaks to me that the Planets4.exe has been DAMAGED?!! and that I must replace it with a good copy!??!?!?!?!? 08 _ I quit and see these error messages: - fixme:string:LCMapStringA (0x0400,0x00400100,0x424bf08c,1,(nil),0): unimplemented flags: 0x00400000 - fixme:string:LCMapStringA (0x0400,0x00400100,0x424bf08c,1,0x4044f048,1): unimplemented flags: 0x00400000 - fixme:string:LCMapStringA (0x0400,0x00400100,0x424bf08c,1,(nil),0): unimplemented flags: 0x00800000 - fixme:string:LCMapStringA (0x0400,0x00400100,0x424bf08c,1,0x4044f048,1): unimplemented flags: 0x00800000 - fixme:dc:GetDCEx new hrgnClip[9722] smashes the previous [96c2] - fixme:dc:GetDCEx new hrgnClip[96be] smashes the previous [9726] And what now? And whenever I minimalize the wine window with the program I cannot get it back to full size (normally ALT SPACE + X) how to do that? -- *º¤., ¸¸,.¤º*¨¨¨*¤ =Oliver@home= *º¤., ¸¸,.¤º*¨¨*¤ I http://www.bmw-roadster.de/Friends/Olli/olli.html I I http://www.bmw-roadster.de/Friends/friends.html I I http://groups.yahoo.com/group/VGAP-93 I I mailto:VGAP-93-subscribe@yahoogroups.com I I http://home.t-online.de/home/spacecraft.portal I >>> Telek0ma iBBMS - now back online +49.4504.TRSi1/TRSi2 <<<

2 1

PSDRV question
by Carl Sopchak 10 Jul '02

10 Jul '02

I've been trying to get Quicken 2000 Deluxe running in wine. After I figured out that it wasn't finding a DLL for the internet connection (and got that fixed), I started testing the second-most important function of Quicken that I need: check printing. All went well until I tried to print a sample check (to verify alignment), at which point Wine crashed into winedbg. I figured out why: When reading the ppd file, it sets up an *InputSlot for ManualFeed (even though it's not really an InputSlot, but most Win programs treat it as one...). The problem was that, in ppd.c, a Name wasn't given to the slot (but a FullName was), so when ps.c tried to output the header for the InputSlot it crashed (since strlen(NULL) causes a crash). I hacked the AddSlot call to name the slot "Manual", and this seems to work OK. The question that I have is, is this the way that it should REALLY get fixed (does the name matter?), or should something else be done? I'd be happy to correct my hack, if necessary. In either case, I can post the patch to sourceforge, once I know "the right way" this should be handled. Thanks for the help, Carl P.S., I added some TRACE() statements to help me debug this. These can be left in the patch that I post, right?

2 2

DOSEMU team
by friest 10 Jul '02

10 Jul '02

1 0

Re: Support for 24bpp when DDBLT_KEYSRC etc are set
by Lionel Ulmer 10 Jul '02

10 Jul '02

> Change log: added support for 24bpp when the flags > DDBLT_KEYSRC/DDBLT_KEYDEST and company are set. Well, I have the following comment : > + case 3: { > + int last_sy = -1; > + for (y = sy = 0; y < dstheight; y++, sy += yinc) { > + sbuf = sbase + (sy >> 16) * sdesc.u1.lPitch; > + if ((sy >> 16) == (last_sy >> 16)) { > + /* this sourcerow is the same as last sourcerow - > + * copy already stretched row > + */ > + memcpy(dbuf, dbuf - ddesc.u1.lPitch, width); Are you sure that this works ? If you have pixels in the destination surface that are NOT overwritten by the source surface (due to color-keying) you should not copy these from one line to the other. > + } else { > + LPBYTE s,d = dbuf; > + for (x = sx = 0; x < dstwidth; x++, sx+= xinc) { > + DWORD pixel; > + > + s = sbuf+3*(sx>>16); > + pixel = (s[0]<<16)|(s[1]<<8)|s[2]; > + if (pixel < keylow || pixel > keyhigh){ > + d[0] = (pixel>>16)&0xff; > + d[1] = (pixel>> 8)&0xff; > + d[2] = (pixel )&0xff; > + d+=3; Why only increase the destination pixel when the color is not keyed off ? > + } > + } > + } > + dbuf += ddesc.u1.lPitch; > + last_sy = sy; > + } > + break;} The rest of the patch looks OK :) By the way, which game uses 24 bpp ? It's *EVIL* :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

No X11 input events in DGA2 mode
by Andy MacLean 10 Jul '02

10 Jul '02

I was trying to run Starcraft under wine in using the X11 DGA2 mode to get a decent frame rate. I tried running it under various versions of wine and got the same result every time. The problem is that when wine runs the game using DGA2 it ignores all input from the keyboard and mouse and so appears to hang. When running the game with DGA2 support disabled (i.e. not running as root) everything works fine but I get a much lower frame rate. I'm new to wine but I had a stab at fixing the problem which as far as I can see is the following: -> wine creates one X11 display connection for each thread and one 'global' display connection to use for various things like DGA2 which it puts in the 'gdi_display' global variable. The thread specific connections get put in x11drv_thread_data structure pointed to by the driver_data pointer in each thread's thread specific structure. -> wine then switches to DGA2 mode if it can and does an 'XSelectInput' to turn on DGA2 input events. It switches to DGA2 mode using the gdi_display connection so all input events will now come through this connection. -> at some point something asks for new X11 events. It goes into the 'X11DRV_MsgWaitForMultipleObjectsEx' function to poll the X11 display connections for each thread. This ends up calling the 'process_events' function in dlls/x11drv/event.c with the 'x11drv_thread_data' structure for each thread. This is the only function that calls 'process_events', which is the only place that calls any X11 event fetching function outside of 'wineclipserv.c' and 'clipping.c' (which seem do something irrelevant to the dga2 problem). -> but process_events can only look at the thread specific X11 display connections since this is the data it gets passed. I cannot find any code which sets up an 'x11drv_thread_data' structure for gdi_display and XNextEvent is only ever called from inside process_events on data->display. Therefore we never poll gdi_display for X11 events at all so I never get any input. I tested this with some debug output code and wine deffinitely never polls gdi_display for events at any time while running the game. X11DRV_MsgWaitForMultipleObjectsEx explicitly does an XFlush on gdi_display as though it is expecting to have to poll it separately, but it never does ... I tried changing 'process_events' in dlls/x11drv/events.c to the following: static int process_events( struct x11drv_thread_data *data ) { XEvent event; int count = 0; wine_tsx11_lock(); while ( XPending( data->display ) ) { XNextEvent( data->display, &event ); wine_tsx11_unlock(); EVENT_ProcessEvent( &event ); count++; wine_tsx11_lock(); } #ifdef FIX_DGA2_INPUT while ( DGAUsed && gdi_display != NULL && data->display != gdi_display && XPending( gdi_display ) ) { XNextEvent( gdi_display, &event ); wine_tsx11_unlock(); EVENT_ProcessEvent( &event ); count++; wine_tsx11_lock(); } #endif wine_tsx11_unlock(); return count; } And this fixed the problem. What's bugging me though is that if this is the correct answer then how do any programs work at all in DGA2 mode? Wouldn't any program hang in the same way as soon as wine switched to DGA2 mode? It would be handy if this were fixed in the wine code so I don't have to keep downloading source and patching so can someone who knows more about the code please let me know if they think this is worth submitting as a patch or point me in the right direction if this is on the wrong track? Thanks in advance, A.

2 2

RE: newbie question
by Medland, Bill 10 Jul '02

10 Jul '02

(BTW HTML email is generally sort of frowned on here) Unix doesn't run windows programs. I suggest you actually read some of the documentation at www.winehq.com <http://www.winehq.com> , especially the Winelib stuff. Basically wine is a Unix program that understands the structure of Windows DLLS and exes. Wine itself runs, loads the dlls and exes into memory and executes them. Some DLLS are replaced by plug-compatible unix so's that interface to the lower levels. So CreateBitmap will eventually result in calls into probably X11 code. Bill -----Original Message----- From: Preetham [mailto:preetham@student.utdallas.edu] Sent: Tuesday, July 09, 2002 5:24 PM To: wine-devel(a)winehq.com Subject: newbie question Hi all: I have a very elementary question. How does the Winodws program run in Unix. For example, i write a program where i call the CreateBitmap() method, what happens. How is a dll called in the unix environment. From what i know, unix dlls are .so files. From the wingdi.h file in the wine\include directory, how does the unix OS know how to resolve the WINAPI call. If i am right, windows dll's are implemented in unix, how is this done. I'm kinda flustered at the moment, would appreciate the help Thanks, Preetham.

4 3

Jump to page:

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