- Wine-devel - list.winehq.org

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

Re: edit control patch
by Ian Pilcher 11 Apr '01

11 Apr '01

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. > Word-wrap is nice. :-) -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

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

11 Apr '01

gerard patel <gerard.patel(a)asi.fr> writes: > I have browsed server/registry.c and it seems that the registry > stores a terminating null for strings; so if you have in the registry > file a string like "0123456789", it get in memory a length of 11. > So I guess that the fix would be to fix the length by -1 somewhere > in the path server->ntdll->advapi No, the current behavior is correct for NT; what you want is a version check to get the Win95 behavior. Something like the patch below should do it (and of course WineMine should be fixed to work on NT too). Index: dlls/advapi32/registry.c =================================================================== RCS file: /opt/cvs-commit/wine/dlls/advapi32/registry.c,v retrieving revision 1.24 diff -u -r1.24 registry.c --- dlls/advapi32/registry.c 2001/03/23 19:12:01 1.24 +++ dlls/advapi32/registry.c 2001/04/09 20:49:35 @@ -640,8 +640,12 @@ { UNICODE_STRING nameW; - if (count && is_string(type)) + if (GetVersion() & 0x80000000) /* win95 */ { + if (type == REG_SZ) count = strlenW( (WCHAR *)data ) + sizeof(WCHAR); + } + else if (count && is_string(type)) + { LPCWSTR str = (LPCWSTR)data; /* if user forgot to count terminating null, add it (yes NT does this) */ if (str[count / sizeof(WCHAR) - 1] && !str[count / sizeof(WCHAR)]) @@ -663,7 +667,11 @@ WCHAR *dataW = NULL; NTSTATUS status; - if (count && is_string(type)) + if (GetVersion() & 0x80000000) /* win95 */ + { + if (type == REG_SZ) count = strlen(data) + 1; + } + else if (count && is_string(type)) { /* if user forgot to count terminating null, add it (yes NT does this) */ if (data[count-1] && !data[count]) count++; -- Alexandre Julliard julliard(a)winehq.com

2 1

VxD information
by Maurice van der Pot 11 Apr '01

11 Apr '01

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. Regards, Maurice van der Pot.

1 0

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

10 Apr '01

Francois Gouget <fgouget(a)free.fr> writes: > But maybe we could ask for traces generated with +relay,+tid instead > of just +relay. > Also when you're working on a specific application for which you have > determined that threads don't play a role, then you would have the > option of omitting the +tid to get simpler traces. I disagree, I think the thread information is important even if you are not chasing a thread problem, simply to tell you which calls are part of the same sequence. It's not possible to make sense of any relay trace if the calls made from different threads cannot be distinguished. If the tid really disturbs you, you can always pipe the output into a sed 's/tid=.*//' or something similar. -- Alexandre Julliard julliard(a)winehq.com

3 2