wine-devel

wine-devel@winehq.org

84463 discussions

Re: debugger startup
by Alexandre Julliard 13 Apr '01

13 Apr '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, this has a major holes: > - since the process creation in Wine knows the created process is not > a PE image, it doesn't set the info on the server side for the newly > created process ; after the exec in the shell script, the info cannot > be retrieved from the parent, hence an error What makes you think that? Of course the info is set for non-PE binaries too, otherwise you could never debug a Winelib app. > perhaps, the best fix would be to merge the init_process/new_process > server calls I don't see how you could possibly do that. new_process is done by the parent, and init_process by the child; they serve very different purposes. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Strange behaviour with GETVDMPOINTER32W
by Alexandre Julliard 12 Apr '01

12 Apr '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Hopefully I get the cutting and pasting right now... > > ... > Call KERNEL.88: LSTRCPY(0x045f781a,0x02ef7044 "%CMDLINE%") ret=02e7:0687 ds=02f7 > Ret KERNEL.88: LSTRCPY() retval=0x045f781a ret=02e7:0687 ds=02f7 > ... > Call KERNEL.516: GETVDMPOINTER32W(0x045f781a,0x0001) ret=02e7:ae4a ds=02f7 > Ret KERNEL.516: GETVDMPOINTER32W() retval=0x404951ba ret=02e7:ae4a ds=02f7 > ... > Call kernel32.lstrcmpA(404951ba "\021\021\021\021\021\021\021\021\021\021\021\021\021\021\0..."...,407e6cbc "%FINDWINDOWCL%") ret=10001464 tid=081df290 Well, either GetVDMPointer returns the wrong pointer, or someone has written to the buffer in the meantime. You need to show us the full trace if you want us to be able to help. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Strange behaviour with GETVDMPOINTER32W
by Alexandre Julliard 12 Apr '01

12 Apr '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > I don't understand this sequence: > > Some strings gets copied to segemented memory > Call KERNEL.88: LSTRCPY(0x046f0018,0x00ef0080 "") ret=02ef:069a ds=02ff > Ret KERNEL.88: LSTRCPY() retval=0x0467781a ret=02ef:0687 ds=02ff lstrcpy is supposed to return its first argument (0x046f0018 in this case). Something is very wrong here... -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: edit control patch
by lawson_whitney＠juno.com 12 Apr '01

12 Apr '01

On Wed, 11 Apr 2001, Dan Engel wrote: > This is my first attempt at submitting a patch--please someone let me know if there are "customs" I need to follow. > Not meaning to beat on you, but - if somebody else patches the same file while you are working on it, it makes garbage of your diff. For a project as big and open as Wine, it is only common sense and common courtesy that we use diff -u. As well as + and - to show what changed, that has also context lines so patch can have some idea if it is FI adding lines where they belong. Besides, Alexandre prefers it. (From <wine>/README, which I think we should all read now and again :-) " If you add something, or fix a bug, please send a patch ('diff -u' format preferred) to julliard(a)winehq.com or to the wine-patches(a)winehq.com mailing list for inclusion in the next release. -- Alexandre Julliard julliard(a)winehq.com " Lawson This message is brought to you by Wine-20010326, junopine-2.0.2, Juno 2.0.11, and pine-4.10 ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: edit control patch
by James Hatheway 12 Apr '01

12 Apr '01

Just one little comment, you should make your diffs using the -u (unified diff) option. (ie. cvs -d $CVSROOT -u controls/edit.c > newdiff.diff) That way your patch has "+"s and "-"s instead of ">"s. It makes it easier to read what is changing in the patch... (For example, you patch will look something like this instead:) + INT BkMode; + BkMode = GetBkMode(dc); + SetBkMode( dc, OPAQUE); + SetBkMode( dc, BkMode); -James -- James Hatheway Work: james(a)macadamian.com ~ http://www.macadamian.com Home: jhatheway(a)home.com ~ http://members.home.net/jhatheway "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer" ----- Original Message ----- From: "Dan Engel" <dengel(a)sourceharvest.com> To: <wine-patches(a)winehq.com> Sent: Wednesday, April 11, 2001 10:24 PM Subject: edit control patch > This is my first attempt at submitting a patch--please someone let me know if there are "customs" I need to follow. > > Problem: Edit boxes are, in some cases, displaying selected text as white-on-white, so that it disappeared. > > Analysis: When text is drawn using the x11drv function X11DRV_ExtTextOut, the function does not paint a background rectangle if the background mode for the device context is transparent. In the case of edit controls, there is no attempt to change the background mode to opaque for selected text. > > Solution: In the case of painting reverse text in the edit control (function EDIT_PaintText) set the backgound mode to opaque, and then restore it before exiting the function. > > The patch is attached (wine.diff). > >

1 0

Strange behaviour with GETVDMPOINTER32W
by Uwe Bonnes 11 Apr '01

11 Apr '01

Hallo, I don't understand this sequence: Some strings gets copied to segemented memory Call KERNEL.88: LSTRCPY(0x046f0018,0x00ef0080 "") ret=02ef:069a ds=02ff Ret KERNEL.88: LSTRCPY() retval=0x0467781a ret=02ef:0687 ds=02ff ... This segmented memory gets mapped to linear memory Call KERNEL.516: GETVDMPOINTER32W(0x0467781a,0x0001) ret=02ef:ae4a ds=02ff Ret KERNEL.516: GETVDMPOINTER32W() retval=0x4043bda2 ret=02ef:ae4a ds=02ff ... Accessing the linear memory returns garbage Call kernel32.lstrcmpA(4043bda2 "\021\021\021\021\021\021... ... ret=10001464 tid=08404b48 I don't see any other accesses to 0x046f:0x0018 or 0x0467781a in between. This happens withthe Encarta 99 setup. Bye Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Free Software: If you contribute nothing, expect nothing --

1 0

Re: debugger startup
by Alexandre Julliard 11 Apr '01

11 Apr '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > either we decide that shell scripts shouldn't be used (easy > solution) or we could do something like : > - if the CreateProcess fails, then wait for a certain amount of > time. If after that time the current process isn't currently > debugged, then report the error. Otherwise assume what did happen is > what has been described above CreateProcess already waits a couple of seconds for the new process to show up, so it's probably enough to simply check for the debugger once CreateProcess returns. An easier fix may be to have the script exec the debugger instead of launching it as a child process; this way the debugger parent pid will be the original Wine process, and everything should work fine. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: VxD information
by Alexandre Julliard 11 Apr '01

11 Apr '01

Maurice van der Pot <griffon26(a)kfk4ever.com> writes: > I'd like to get started on VxD support, but I'm unable to find any useful > documentation on how it's implemented in Wine. I've been looking through > the sources (e.g. vxd.c, wprocs.spec) but I can't find the connection > between a call to int 2F and a call to the functions in vxd.c. The connection is through int 2f ax=0x1684 (in msdos/int2f.c), which does a GetProcAddress on wprocs and returns the vxd entry point to the application. The app then calls the corresponding vxd directly with a normal function call. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: RegSetValueEx problem?
by Alexandre Julliard 11 Apr '01

11 Apr '01

davep <davep(a)cyw.uklinux.net> writes: > I have now been able to build and run WineMine under NT4, and it works > perfectly. On exit each parameter is saved to the registry as 16 bytes including > the training garbage (not visible in Regedit of course) and when restarted the > exact same 16 bytes are reloaded from the registry. > > It does therefore seem that there is something wrong with Wne's implementation. No, it depends if data[sizeof(data)] is null or not; the +1 on the size is done only if the last byte is null, on the assumption that the programmer forgot to count it (i.e. used strlen(data) instead of strlen(data)+1). It's the usual Microsoft approach of hiding bugs instead of fixing them, and it is definitely what NT does (or we wouldn't be doing such a monstrosity). Now what can happen is that the Microsoft compiler lays out the stack in a different way than gcc, and that the variable that is just above the array on the stack doesn't contain 0 in this case. In fact I suspect that if you run your Windows binary of WineMine under Wine it will work fine too. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Traces: fs -> tid
by Alexandre Julliard 11 Apr '01

11 Apr '01

Francois Gouget <fgouget(a)free.fr> writes: > Yes, but it would also be the simplest implementation (overdesign can > be ugly too). And if it's the one off hack that it current looks like it > is, why not. > I propose to just let Alexandre decide which implementation, if any, > he thinks would be worth including in CVS. I think we have now wasted enough bandwidth on this non-issue. The relay traces have always displayed the thread info, and will continue to do so. People who are morally offended by the extra 5 characters needed for the tid can hack their local tree, or learn to use sed/awk/perl. -- Alexandre Julliard julliard(a)winehq.com

1 0

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