July 2002 - Wine-Devel - list.winehq.org

DOSEMU team

by friest

July 10, 2002

Re: RFC: Re: [ros-kernel] Shell32 and dplax

by Eric Pouech

> IMHO the way WINE handles certain things is really > fubar. basically, since Wine evolves like Windows did (16 bit => win32 à la Win9x => NT infra), wine suffers from the same defaults :-( however, I agree with you that spreading wineserver calls all over the DLLs is a bad idea IMO, the ultimate design would be to only have wineserver calls in NTDLL, but that's a long way to go... it would permit nice things as: - portability on windows for testing the various DLLs - (should be good for ReactOS) - would allow to resign drop in replacement for NTDLL, like moving (part of) wineserver inside the Linux kernel - ... to start with, I think keeping the wineserver calls only in the holy three DLLs should be an acceptable short term target BTW, I did extend a bit the PSAPI implementation (for some missing API) and was also upset by the calls to toolhelp for that in short, moving to NT architecture is the way to go, but it'll need some time may be we could also create a metabug on bugzilla for this and link all known issues to this meta-bug. A+

July 10, 2002

Re: Any advice on how to debug this?

by Eric Pouech

> 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+

July 10, 2002

Re: Debugger

by Eric Pouech

Max a écrit : > > thanx !!! > 3 - Starting an app in winedbg (no symbol table for app...), debugger sometimes stops at app entry point > (as I guess it should), sometimes before.... Is there a way to make it stop on app entry point, even with > no symbols loades ? Or, even better.... there's a known (easy !) way to attach symbols generated by > a disassembler (i.e. the best one, IDA) ? I've done it in windoze many times, with IDA+Soft-ICE, and > it helps a lot ! the "symbolfile foo" used to load the file foo and add symbol from it format of file foo is the regular unix format xxxxxxxx T name where xxxxxxxx address of symbol T type of symbol name string that describes the symbol I think it should still be working (untested though) dunno either if symbols generated by IDA and other tools will fit the format of the file note also that you may have to relocate the adress depending on the load address of the module the symbols are for (which, if needed, needs to be done at the file level) the attached patch should extent the symbolfile command like: symbolfile foo 0x12345678 to relocate symbols from foo at address 0x12345678 (assuming address in foo are relative to the start of the module) A+ Name: wdbg_sym ChangeLog: added offset for relocating symbols in symbolfile command License: X11 GenDate: 2002/07/10 11:54:38 UTC ModifiedFiles: debugger/debugger.h debugger/dbg.y debugger/hash.c AddedFiles: =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/debugger.h,v retrieving revision 1.35 diff -u -u -r1.35 debugger.h --- debugger/debugger.h 13 Jun 2002 21:37:07 -0000 1.35 +++ debugger/debugger.h 10 Jul 2002 11:52:17 -0000 @@ -358,7 +358,7 @@ struct name_hash ** rtn, unsigned int ebp, struct list_id * source); -extern void DEBUG_ReadSymbolTable( const char * filename ); +extern void DEBUG_ReadSymbolTable( const char * filename, unsigned long offset ); extern void DEBUG_AddLineNumber( struct name_hash * func, int line_num, unsigned long offset ); extern struct wine_locals * Index: debugger/dbg.y =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/dbg.y,v retrieving revision 1.57 diff -u -u -r1.57 dbg.y --- debugger/dbg.y 2 Jun 2002 21:36:08 -0000 1.57 +++ debugger/dbg.y 10 Jul 2002 11:52:04 -0000 @@ -156,7 +156,8 @@ | tUNDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } | tCOND tNUM tEOL { DEBUG_AddBPCondition($2, NULL); } | tCOND tNUM expr tEOL { DEBUG_AddBPCondition($2, $3); } - | tSYMBOLFILE pathname tEOL { DEBUG_ReadSymbolTable($2); } + | tSYMBOLFILE pathname tEOL { DEBUG_ReadSymbolTable($2, 0); } + | tSYMBOLFILE pathname tNUM tEOL { DEBUG_ReadSymbolTable($2, $3); } | tWHATIS expr_addr tEOL { DEBUG_PrintType(&$2); DEBUG_FreeExprMem(); } | tATTACH tNUM tEOL { if (DEBUG_Attach($2, FALSE)) return 1; } | tDETACH tEOL { DEBUG_ExitMode = EXIT_DETACH; return 1; } Index: debugger/hash.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/debugger/hash.c,v retrieving revision 1.30 diff -u -u -r1.30 hash.c --- debugger/hash.c 31 May 2002 23:06:46 -0000 1.30 +++ debugger/hash.c 10 Jul 2002 11:53:12 -0000 @@ -797,7 +797,7 @@ * * Read a symbol file into the hash table. */ -void DEBUG_ReadSymbolTable( const char* filename ) +void DEBUG_ReadSymbolTable( const char* filename, unsigned long offset ) { FILE * symbolfile; DBG_VALUE value; @@ -839,7 +839,12 @@ if (!(*cpnt) || *cpnt == '\n') continue; if (sscanf(buffer, "%lx %c %s", &value.addr.off, &type, name) == 3) + { + if (value.addr.off + offset < value.addr.off) + DEBUG_Printf( DBG_CHN_WARN, "Address wrap around\n"); + value.addr.off += offset; DEBUG_AddSymbol( name, &value, NULL, SYM_WINE ); + } } fclose(symbolfile); }

July 10, 2002

Re: Support for 24bpp when DDBLT_KEYSRC etc are set

by Lionel Ulmer

> I do not have any game that uses 24 bits (to the best of my knowledge) > This is more of an exersize in getting to know the code better. Of > course if we don't want to support 24 bpp... No, it's fine to support it. I was just curious that's all :-) > Thankyou for looking at it, I will have to do some changes before I > resubmit. No problem... Peer review is always a good way to find bugs before committing to CVS. Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 10, 2002

Re: warcraft 3

by Lionel Ulmer

On Tue, Jul 09, 2002 at 06:08:07PM +0200, Matthieu Foillard wrote: > Using winex using opengl (compiled from cvs), start using wine > path/War3.exe -- -opengl : > it prints : > fixme:opengl:wglSwapLayerBuffers (): stub ! > fixme:opengl:wglSwapLayerBuffers (): stub ! > fixme:opengl:wglSwapLayerBuffers (): stub ! This is fixed in the WineHQ CVS tree. You just need to wait for the patch to do the WineHQ => ReWind => WineX path (as it's X11 licensed) :-) Or you can also apply the patch yourself to your CVS WineX tree. Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 10, 2002

Re: newbie question

by Michael Cardenas

Preetham wrote: > Thanx bill. But what i want to know is where exactly is this > call(CreateBitmap will eventually result in calls into probably X11 > code) done. I have looked into the documentation in winehq.com, i get > a fair idea of how it is done, however when i look into the source > code, im unable to understand much. > What i want to know is, this program that loads the windows exe and > which runs them, where is this program located. > Also, the code where CreateBitmap is mapped into the Xlib, where is > this code. > I am looking at some kind of low level documentation, or atleast a > place where i could start. > Thanks, > Preetham > > ----- Original Message ----- > > *From:* Medland, Bill <mailto:Bill.Medland(a)accpac.com> > *To:* Wine devel (E-mail) <mailto:wine-devel(a)winehq.com> > *Sent:* Tuesday, July 09, 2002 4:10 PM > *Subject:* RE: newbie question > > (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. > ... > You could start by going to your wine source dir and typing this: find . -name *.c | grep CreateBitmap or find . -name *.spec | grep CreateBitmap -- michael cardenas lead windows compatibility engineer lindows.com . hyperpoem.net . "Be the change you want to see in the world" -Mahatma Gandhi

July 10, 2002

Re: Bad exe

by admiral coeyman

Uwe Bonnes, > > Alexandre submitted something with regard to 16 bit yesterday > (wine/dlls/version info.c). Remove this and if that doesn't help remove all > other yesterdays patches step by step. > This problem, 'invalid exe file,' is not that new. I've been having it for a little while. It seems that all of the programs compiled under gcc work. No other dos executable is currently working. I am just checking to see if anybody else is having this problem to see if this is something that I need to patch or if it's a problem with my system. Does anybody else run a test dos executable that is 16 bit? God Bless, --Robert 'Admiral' Coeyman -- --- May you live as long as you wish and age but a single day. http://www.dotguy.net/ admiral(a)corner.net Webmaster/ Linux Administrator Computer Co-Op/CornerNet

July 10, 2002

Re: No X11 input events in DGA2 mode

by Andy MacLean

Lionel Ulmer wrote: > >You can see that this topic was already debated in the following threads : > > http://www.winehq.com/hypermail/wine-devel/2002/06/0396.html > >And even earlier here : > > http://www.winehq.com/hypermail/wine-devel/2002/01/0392.html > > Thanks, I probably should have searched the archive first before jumping in and posting. Had a read of the previous threads and I'm still trying to understand exactly what's wrong with the fix, here are some questions: -> if gdi_display gets replaced with the thread specific display, won't this cause more problems than it fixes? Would a windows program not expect to be able to switch on directX in one thread then operate on the raw display from any thread? Using the thread specific display would require the thread which switched DGA2 on to perform all operations because most DGA2 calls throw errors if a display is not in DGA2 mode and only one display can be in this mode at any one time. -> In a multi-threaded program, does it matter which WaitForMultipleObjects is used to collect the events? The event gets dispatched to the wineserver with the DGA window's hWnd attached in the same way as it would if 'emulated' direct access were used (i.e. drawing with normal X11 calls). This then sends the event on to the windows program. If this is a problem then wouldn't it also affect non-DGA2 modes and therefore be a separate problem? It's been ages since I did any windows programming (win 3.1), what would a multi-threaded windows app expect to happen if it starts multiple threads and runs more than one event loop? Perhaps a better fix might be to have a thread 'own' the gdi_display if it switches DGA2 mode on. The X11drv_thread_data structure for each thread could get a new 'gdi_display' field which would default to NULL. This could get set to the global gdi_display field for the thread which switches on DGA2 and process_events could be changed to poll data->gdi_display in addition to data->display if this was non-null. I think this would produce input event behaviour identical to the 'emulated' DGA2 mode since DGA2 events would only be handled when the thread which entered DGA2 mode was polled for events. A.

July 10, 2002

Re: Support for 24bpp when DDBLT_KEYSRC etc are set

by Tony Lambregts

Lionel Ulmer wrote: >>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. > > Doh! > > >>+ } 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 ? > Doh!! > > > >>+ } >>+ } >>+ } >>+ 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* :-) > I do not have any game that uses 24 bits (to the best of my knowledge) This is more of an exersize in getting to know the code better. Of course if we don't want to support 24 bpp... Thankyou for looking at it, I will have to do some changes before I resubmit. Tony Lambregts

July 10, 2002