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

Re: winedbg again :-)

by Eric Pouech

> > OTOH, it's also very awful to set a bp on memory which isn't mapped > > yet... you > > cannot write on it :-) > > anyway, we could do something like we do now for bp setting (expressed > > as a string) and automatically set the bp on DLL loading (if we can) > > rather easy (just follow what's done for deferred bp) > > Yes, I meant deferred BP... is there already a way to set them now, at adress > points ? Or it's only for source BPs ? this works now for function names (but not source bp like file.c at line 123, nor for addresses) I'm currently finishing a patch that implements what you want > > that's a bit harder (especially, since we don't want the user to > > interact), but basically it's just setting the parser to read from a > > file stream instead of stdin > > I don't understand the thing of avoiding user interaction.... I was thinking about a > command like 'store breaks <filename>' and > 'load breaks <filename>... or maybe, better, a way to store all winedbg settings on > file. I've almost finished the 'source foo' winedbg commands, which will read all (winedbg) commands stored in file foo. what you propose if way too specific to your current problem. but the 'source' command, there shouldn't be any user interaction (like asking the user for some more information) A+

July 29, 2002

Re: winedbg again :-)

by Max

Alle 18:24, lunedì 29 luglio 2002, Eric Pouech ha scritto: ............ > this works now for function names (but not source bp like file.c at line > 123, nor > for addresses) > I'm currently finishing a patch that implements what you want > great, I think even it can be dangerous, it can spare much debugging time too! ............... > I've almost finished the 'source foo' winedbg commands, which will read > all (winedbg) commands stored in file foo. what you propose if way too > specific to your current problem. but the 'source' command, there > shouldn't be any user interaction (like asking the user for some more > information) yes, I meant something like that.... Quite like a command macro recorder, or a simpler a scripting ability. It happens often to loose much time to reach the correct debugging point, and then loose the command sequence to reach it... I guess with your patch that'll be much better Btw, I tried GDB with wine, but it's really awful that it doesn't understand threading/process modell of wine, so I went back to winedbg. Tried your remote add-on too, but no success... maybe I did something wrong. I'm thinking more and more to write a graphical front-end for winedbg, maybe using as a starting point KDBG... Simple and clean interface, not too many complicated (and also quite unuseful :) ) commands.... I 'now that it'll never (?) go in cvs, but it can be useful as an external add-on too.... A little (and maybe dummy, as usual!) question : as winedbg is a winelib app, is it possible to link it with QT, or there are some known problems ? Regards (and thanx for the patches !) Max

July 29, 2002

Re: game patches

by Serge Ryabchun

On Mon, 29 Jul 2002, Lionel Ulmer wrote: > I think these are WineX patches.. yes, sorry, but these patches and spec for them who want to play games for example SeriousSam, HL or WarCraftIII with more speed and who used winex ;-) just rpm -bs; rpm -rebuild --target i686; rpm -i; enjoy ;-) > > Which application needs to have the 'PFD_SWAP_COPY' flag set ? SeriousSam & SeriousSam-SE, comments for this was in .spec. > > Well, this part is actually one of my patches submitted to WineHQ some time > ago :-) sure, comments for this was in .spec too > > > -$ext_prefix = "func_"; > > +$ext_prefix = ""; > > Why change the 'ext_prefix' ? oops ;-) but and for this was comments in .spec ;-) -- Serge Ryabchun sr(a)energy.uch.net

July 29, 2002

Re: game patches

by Lionel Ulmer

I think these are WineX patches.. So you should clean the parts that are NOT WineX specific and resubmit them only here.. Moreover, it is often preferred (even recommanded) to NOT send a huge patch with a bunch of unrelated diffs in it but atomic changes. For example, why mix D3D changes, OpenGL changes and DGA2 changes considering that they all are related to different games / applications ? As for the pure WineX changes, I do not know where to submit :-) For some changes, see my comments embedded.. Lionel > --- wine-cvs/graphics/x11drv/opengl.c Wed Aug 29 22:37:08 2001 > +++ wine/graphics/x11drv/opengl.c Sat Jul 20 10:07:05 2002 > @@ -200,7 +200,7 @@ > ppfd->nVersion = 1; > > /* These flags are always the same... */ > - ppfd->dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_GENERIC_ACCELERATED; > + ppfd->dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_SWAP_COPY; > /* Now the flags extraced from the Visual */ > ENTER_GL(); > glXGetConfig(gdi_display, vis, GLX_DOUBLEBUFFER, &value); if (value) ppfd->dwFlags |= PFD_DOUBLEBUFFER; Which application needs to have the 'PFD_SWAP_COPY' flag set ? > --- wine-cvs/include/wingdi.h Mon Apr 22 10:01:17 2002 > +++ wine/include/wingdi.h Sat Jul 20 13:22:05 2002 > @@ -3345,6 +3345,39 @@ > BOOL WINAPI PolyTextOutW(HDC,PPOLYTEXTW,INT); > #define PolyTextOut WINELIB_NAME_AW(PolyTextOut) > > +/* These defines are used by wglSwapLayerBuffers */ > +#define WGL_SWAP_MAIN_PLANE (1 << 0) (snip) > + WARN("Following layers unhandled : %08x\n", fuPlanes); > + } > + > + return TRUE; > } > > /*********************************************************************** Well, this part is actually one of my patches submitted to WineHQ some time ago :-) > # Prefix used for the local variables > -$ext_prefix = "func_"; > +$ext_prefix = ""; > # If set to 1, generate TRACEs for each OpenGL function > -$gen_traces = 1; > +$gen_traces = 0; Why change the 'ext_prefix' ? I could understand that you want more speed and remove the (mostly useless now) ENTER/LEAVE calls and the TRACES, but that one I do not understand :-) (big snip removed) -- Lionel Ulmer - http://www.bbrox.org/

July 29, 2002

Re: bugzilla privs

by Andriy Palamarchuk

--- Michael Stefaniuc <mstefani(a)redhat.de> wrote: > Hello, > > could somebody please give me the necessary privs so > I can take > ownership of wine bugs (account > mstefani(a)redhat.com) > If not please close bugs #483, #489, #502. With big pleasure. Let me know if you still have any problems. Andriy __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com

July 29, 2002

game patches

by Serge Ryabchun

comments in spec -- Serge Ryabchun sr(a)energy.uch.net

July 29, 2002

Re: PATCH: [Bug 19] - font enumeration problems for aliased gdi fonts

by Huw D M Davies

On Thu, Jul 25, 2002 at 12:43:37PM -0700, Rafael Kitover wrote: > Huw D M Davies wrote: > > What's exactly the problem here? Is it lack of support of 16bit EnumFonts ? > > > > Huw. > > The problem is this line in X11DRV_EnumDeviceFonts: > > if (physDev->dc->gdiFont) return FALSE; > > so if the font is "MS Sans Serif", it will return 0, and old VB apps at least > won't like that. But knowing the actual X11 font name given in the wine config, > from the alias table it's possible to enumerate it, so those apps will start, > that's what that patch does. > > That's all I really managed to understand here, if there is a better way to do > this I will. The alias table in the config file is used only by the old font scheme. Could you send me a relay trace of what's going on, I'd like to understand why VB apps have problems. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

July 29, 2002

bugzilla privs

by Michael Stefaniuc

Hello, could somebody please give me the necessary privs so I can take ownership of wine bugs (account mstefani(a)redhat.com) If not please close bugs #483, #489, #502. thanks bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

July 29, 2002

Re: PATCH: temp fixes, again

by Marcus Meissner

On Sat, Jul 27, 2002 at 09:13:09AM -0700, WINE wrote: > Marcus Meissner <meissner(a)suse.de> writes: > > > This has been some time ago, and those old libc versions should not be used > > anymore for security reasons. > > Well the man page says "Don't use this function", and if it's broken > in old glibc it can be broken on other systems too. I think it's safer > to do the open ourselves, especially since this is pretty trivial to > do. Actually there are a lot of programs using mkstemp now and it would be terrible if they were all broken. > > If you have a description on what was broken I can whip up a configure > > check though. > The bug is that the temp file is created with mode 0666. But you can't > do a configure check for a run-time feature/bug anyway. According to my manpage this was fixed in glibc 2.0.7, which was released 3 years ago. I do not see why we should not use mkstemp, it is one of the canonical ways of creating tempfiles throughout the security community. Ciao, Marcus

July 29, 2002

Re: question on _lclose16

by Ove Kaaven

On Sat, 27 Jul 2002, Rafael Kitover wrote: > In files/file.c, line 1351: > > HFILE16 WINAPI _lclose16( HFILE16 hFile ) > { > if (hFile < 5) > { > FIXME("stdio handle closed, need proper conversion\n" ); > SetLastError( ERROR_INVALID_HANDLE ); > return HFILE_ERROR16; > } > .... > > > What does this mean? Taking it out doesn't seem to hurt anything. I > understand from this block: > > static void FILE_InitProcessDosHandles( void ) > { > dos_handles[0] = GetStdHandle(STD_INPUT_HANDLE); > dos_handles[1] = GetStdHandle(STD_OUTPUT_HANDLE); > dos_handles[2] = GetStdHandle(STD_ERROR_HANDLE); > dos_handles[3] = GetStdHandle(STD_ERROR_HANDLE); > dos_handles[4] = GetStdHandle(STD_ERROR_HANDLE); > } > > why we don't want to close those handles probably. Actually I guess it could be fixed by making the dos_handles[x] *duplicates* of the standard win32 handles, i.e. DuplicateHandle(GetCurrentProcess(), GetStdHandle(...), ...). If then a dos app tries to close those standard handles, only the duplicate will be closed, not the win32 std handle itself. > But why would I see that message, do sloppy windows programs try to > close a range of handle numbers or something? Yeah, I've seen some apps do just that. But it could also be trying to close a stdin/out handle in preparation for doing redirection.

July 28, 2002