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

Re: [PROBLEM REPORT] Edit control line scrolling

by Bill Medland

Gerard Patel <gerard.patel(a)nerim.net> wrote in article <1.5.4.32.20010723223108.4150002c(a)pop.nerim.net>... > With programs using a multiline edit control, such as Notepad (I'm using Win3.11 > version) or Eudora Light 1.5 with mails from the 'In' mailbox (this is a 32 bits > application), scrolling down the edit buffer line by line mostly does not work. > > In fact, it works only if the edit buffer size is an exact multiple of the > line height. > > In all other cases, the format rectangle is smaller than the client size, > and when > the edit control tries to redraw the last line, the update rectangle is > wrong : only the > lower part of the line is drawn. > > I think that this problem can be traced to the replacement of code in > ScrollWindowEx > by the call to ScrollDC. > > What is happening is that the client rectangle is scrolled, but the client > rectangle is > bigger than the formatting rectangle by a few pixels; these pixels are > missing in > the update region. > > In Wine previous version, the client rectangle was first ANDed with the > so-called > 'visible region' (hvisRgn), so the result was not bigger than the format > rectangle > before being scrolled, then diff-ed with it. > > The following patch works around this problem. > > I don't have time to investigate further as I am taking one week of > holidays :-) but if someone is interested in the edit control.... > > Gerard > > > Index: dlls/x11drv/scroll.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/scroll.c,v > retrieving revision 1.2 > diff -u -r1.2 scroll.c > --- dlls/x11drv/scroll.c 2001/06/20 00:18:48 1.2 > +++ dlls/x11drv/scroll.c 2001/07/22 22:12:06 > @@ -114,7 +114,7 @@ > hrgn2 = CreateRectRgnIndirect( &rect ); > if (hrgn) SetRectRgn( hrgn, rClip.left, rClip.top, rClip.right, > rClip.bottom ); > else hrgn = CreateRectRgn( rClip.left, rClip.top, rClip.right, > rClip.bottom ); > - CombineRgn( hrgn, hrgn, hrgn2, RGN_AND ); > + CombineRgn( hrgn2, hrgn, hrgn2, RGN_AND ); > OffsetRgn( hrgn2, dx, dy ); > CombineRgn( hrgn, hrgn, hrgn2, RGN_DIFF ); > > > > > If anyone does start looking at this, watch out for the following. I haven't looked closely and admit that I probably left the code very slightly incorrect for a degenerate case. I think that in the case of a single border (is WS_BORDER, no WS_CLIENTEDGE etc) then the edit control fiddles things so that it pretends it doesn't have a border (i.e. there is no non-client rectangle) and it draws the border itself. This is possibly unusual; I believe that most controls leave the border drawing to the NC_ code. Since I don't think WS_BORDER is specified alone in most cases I doubt if this is a problem in reality. Bill

July 23, 2001

Why is this wrong?

by Bill Medland

The code of "perfect_graphics" (attached) gives my system problems. The visible aspect of the problem is that the text in our application's listview doesn't get drawn properly. By experimentation I have narrowed it down to when perfect_graphics was edited. I observe that our application works correctly under the two following cases: 1. When the body of the function is removed and the value is hard-coded to true 2. When the "inline" is removed (which is the fix I am proposing and will submit in a moment) Since I do not like working without understanding I would like to know: Is there something wrong with the use of "inline" in this context? Or is there clearly something wrong with my build environment? Or is everyone else as confused by it as me? TIA Bill begin 600 e1 M+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ#0H@*B @(" @(" @(" @<&5R M9F5C=%]G<F%P:&EC<PT*("H-"B J($9A=F]R(&-O<G)E8W1N97-S(&]R('-P M965D/PT*("HO#0IS=&%T:6,@:6YL:6YE(&EN="!P97)F96-T7V=R87!H:6-S M*'9O:60I#0I[#0H@(" @<W1A=&EC(&EN="!P97)F96-T(#T(a)+3$[#0H@(" @ M:68@*'!E<F9E8W0@/3T(a)+3$I#0H@(" @>PT*"4A+15D@:&ME>3L-"@EC:&%R M(&)U9F9E<ELR,%T[#0H)+RH(a)9&5F875L="!V86QU92 J+PT*"7!E<F9E8W0@ M/2 P.PT*"6EF*"%296=/<&5N2V5Y02A(2T597TQ/0T%,7TU!0TA)3D4L(")3 M;V9T=V%R95Q<5VEN95Q<5VEN95Q<0V]N9FEG7%QX,3%D<G8B+" F:&ME>2DI M#0H)>PT*"2 @("!$5T]21"!T>7!E+"!C;W5N=" ]('-I>F5O9BAB=69F97(I M.PT*"2 @("!I9B(a)A4F5G475E<GE686QU945X02AH:V5Y+" B4&5R9F5C=$=R M87!H:6-S(BP@,"P@)G1Y<&4L(&)U9F9E<BP@)F-O=6YT*2D-"B @(" @(" @ M(" @('L-"B @(" @(" @(" @(" @("!C:&%R(&-H(#T(a)8G5F9F5R6S!=.PT* M(" @(" @(" @(" @(" @('!E<F9E8W0@/2 H8V@@/3T@)WDG('Q\(&-H(#T] M("=9)R!\?"!C:" ]/2 G="<@?'P(a)8V@@/3T@)U0G('Q\(&-H(#T]("<Q)RD[ M#0H@(" @(" @(" @("!]#0H)(" @(%)E9T-L;W-E2V5Y*&AK97DI.PT*"7T- @"B @("!]#0H@(" @<F5T=7)N('!E<F9E8W0[#0I]#0IY ` end

July 23, 2001

Re: Executable permissions on .exe/.com files

by Alexandre Julliard

Bernhard Rosenkraenzer <bero(a)redhat.de> writes: > Since some people will probably want to use BINFMT_MISC or similar > functionality to run wine transparently, I think we need the possibility > to set executable permissions on wine-generated (e.g. by "wine setup.exe") > .exe/.com files. > > This patch implements this (optionally - new configure switch). I have applied it, but without the configure switch. I think it should be OK to always set the permissions, and if it turns out to cause trouble we should add a run-time option, not a compile-time one. -- Alexandre Julliard julliard(a)winehq.com

July 23, 2001

Re: implement BuildCommDCB16 using BuildCommDCB

by lawson_whitney＠juno.com

On Mon, 23 Jul 2001 16:59:35 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_80675836 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > This (untested) patch completes the COMM16 code seperation. The > COMM16 > code can now be moved into USER (i think). > > Mike Juno 1.49 finds no fault with this, but AFAICS from a comm trace, the app doesn't use the DCB functions, so this is not such a conclusive test. Anybody else have any 16 bit comms apps? Lawson ---oof--- > ChangeLog: > rewrite BuildCommDCB16 to depend on BuildCommDCB, not vice-versa > ________________________________________________________________ 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.

July 23, 2001

Re: Still problems with snoop

by Uwe Bonnes

>>>>> "Francois" == Francois Gouget <fgouget(a)free.fr> writes: Francois> On Mon, 23 Jul 2001, Uwe Bonnes wrote: >> Hallo, >> >> some days ago I reported early crashes when running with the snoop >> debug option. E.g. vc98 msedv.exe is a good example. Running with >> "+snoop" crashes early. Running with "-snoop=devshl" lets the program >> succeed much further. Running without snoop gets even substancial >> further. >> >> So I think there must be something wrong with snoop. I tried to look >> hard at relay32/snoop.c, but didn't see anything fishy. So perhaps >> somebody else has some idea what's going wrong. Francois> Some time ago I found that we would crash in SNOOP_PrintArg Francois> when x==-1, eventhough it's all in a try/catch. I didn't get Francois> time to investigate in detail. You can try to see if this Francois> patch makes things better (the traces are there for debug in Francois> case you remove the -1 test): Francois, thanks for your help. However the crash happens miles away from an snoop entry or exit in an MFC42 function, so the patch doesn't help: 080672b0:CALL mfc42.5163: ?OnWndMsg(a)CWnd@@MAEHIIJPAJ(a)Z(00000081,00000000,405f5ad4,405f5728) ret=5f447664 ^^^^^^^^^^^^^^ 080672b0:CALL msvcrt.67: _EH_prolog(40f9007d,00000081,00000000,405f5ad4,405f5728,00000081,40a96dc0,40 400c48,00000000,405f5748,40f90064,00000081,00000000,405f5ad4,40a96dc0,40a96dc0, ...) ret=5f4476a4 080672b0:RET msvcrt.67: _EH_prolog() retval = 40f90096 ret=5f4476a4 080672b0:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006bc87 080672b0:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006bc87 ... 080672b0:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006bc87 080672b0:CALL msvcrt.203: _except_handler3(<unknown, check return>) ret=4006bc87 080672b0:CALL msvcrt.73: _XcptFilter(<unknown, check return>) ret=0040175d fixme:pthread_kill_other_threads_np WineDbg starting... on pid 8068990 No debug information in 32bit DLL '<Debugged process>' (0x00400000) Loaded debug information from ELF 'wine' (0x00000000) Breakpoint 1 at 0x4000da00 (_end+0x37fc1284) Loaded debug information from ELF '/spare/bon/wine/dlls/libntdll.so' (0x40026000) ... =>0 0x5f4475da (?AfxFindMessageEntry@@YGPBUAFX_MSGMAP_ENTRY@@PBU1(a)III@Z+0x10 in C:\NT4SP5G\SYSTEM32\MFC42.DLL) (ebp=405f567c) 1 0x5f44780a (?OnWndMsg(a)CWnd@@MAEHIIJPAJ(a)Z+0x170 in C:\NT4SP5G\SYSTEM32\MFC42.DLL) (ebp=405f5704) ^^^^^^^^^^^^^ 2 0x40f9007d (_end+0x2a1edd) (ebp=405f572c) 3 0x40f90064 (_end+0x2a1ec4) (ebp=405f5748) 4 0x50301f1f (DEVPRJ.PKG..text+0xf1f in C:\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=405f5764) For me it seems, that at some point we get different arguments back from a dll when run with snoop versus running without snoop. I don't expect subtile timing problems, as the crash happens deterministic. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 23, 2001

Re: Still problems with snoop

by Francois Gouget

On Mon, 23 Jul 2001, Uwe Bonnes wrote: > Hallo, > > some days ago I reported early crashes when running with the snoop debug > option. E.g. vc98 msedv.exe is a good example. Running with "+snoop" crashes > early. Running with "-snoop=devshl" lets the program succeed much > further. Running without snoop gets even substancial further. > > So I think there must be something wrong with snoop. I tried to look hard at > relay32/snoop.c, but didn't see anything fishy. So perhaps somebody else has > some idea what's going wrong. Some time ago I found that we would crash in SNOOP_PrintArg when x==-1, eventhough it's all in a try/catch. I didn't get time to investigate in detail. You can try to see if this patch makes things better (the traces are there for debug in case you remove the -1 test): --- cut here --- Index: relay32/snoop.c =================================================================== RCS file: /home/wine/wine/relay32/snoop.c,v retrieving revision 1.44 diff -u -r1.44 snoop.c --- relay32/snoop.c 2001/07/18 20:00:06 1.44 +++ relay32/snoop.c 2001/07/20 23:31:02 @@ -212,7 +214,7 @@ int i,nostring; char * volatile ret=0; - if ( !HIWORD(x) ) { /* trivial reject to avoid faults */ + if ( !HIWORD(x) || x==-1 ) { /* trivial reject to avoid faults */ sprintf(buf,"%08lx",x); return buf; } @@ -220,9 +222,13 @@ LPBYTE s=(LPBYTE)x; i=0;nostring=0; while (i<80) { + if (x==-1) TRACE("%d: i=%d\n",__LINE__,i); if (s[i]==0) break; + if (x==-1) TRACE("%d: i=%d\n",__LINE__,i); if (s[i]<0x20) {nostring=1;break;} + if (x==-1) TRACE("%d: i=%d\n",__LINE__,i); if (s[i]>=0x80) {nostring=1;break;} + if (x==-1) TRACE("%d: i=%d\n",__LINE__,i); i++; } if (!nostring) { --- cut here --- -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

July 23, 2001

Re: Microsoft source code releases - a danger to Wine?

by Bill Medland

Ian Pilcher <ian.pilcher(a)home.com> wrote in article <3B59F1DE.5010904(a)home.com>... > According to Slashdot, Microsoft has released the Windows CE source code > under one of their "shared source" licenses. Needless to say, it would > be an *extremely* bad idea for anyone associated with the Wine project > to look at it. I must admit that as a newcomer to the Wine project I would appreciate a little guidance on what are and are not valid methods for investigating Windows sufficiently to work on the Wine project. This cuts two ways: 1. What methods are accepted as legal for obtaining information and what methods must not be used (in order to protect Wine) 2. What methods are especially effective and what methods are a waste of time (in order to improve the learning curve for contributors) Should there be a section in the Wine Development HQ (Or is it already there and I missed it). Bill

July 23, 2001

Re: PATCH: msvcrt.ungetc

by Marcus Meissner

On Sun, Jul 22, 2001 at 03:40:24PM -0700, Alexandre Julliard wrote: > Marcus Meissner <marcus(a)jet.franken.de> writes: > > > --- include/msvcrt/stdio.h 2001/05/07 18:18:34 1.2 > > +++ include/msvcrt/stdio.h 2001/07/21 12:43:43 > > @@ -72,6 +72,7 @@ > > int _charbuf; > > int _bufsiz; > > char* _tmpfname; > > + int _ungetc; > > } MSVCRT(FILE); > > You cannot do that, the FILE structure has to remain binary > compatible. Hmm. Properly implementing would mean writing a complete stdio FILE* implementation, including buffer handling, which is currently too much work for me. Ciao, Marcus

July 23, 2001

Still problems with snoop

by Uwe Bonnes

Hallo, some days ago I reported early crashes when running with the snoop debug option. E.g. vc98 msedv.exe is a good example. Running with "+snoop" crashes early. Running with "-snoop=devshl" lets the program succeed much further. Running without snoop gets even substancial further. So I think there must be something wrong with snoop. I tried to look hard at relay32/snoop.c, but didn't see anything fishy. So perhaps somebody else has some idea what's going wrong. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 23, 2001

Re: PATCH: msvcrt.ungetc

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > --- include/msvcrt/stdio.h 2001/05/07 18:18:34 1.2 > +++ include/msvcrt/stdio.h 2001/07/21 12:43:43 > @@ -72,6 +72,7 @@ > int _charbuf; > int _bufsiz; > char* _tmpfname; > + int _ungetc; > } MSVCRT(FILE); You cannot do that, the FILE structure has to remain binary compatible. -- Alexandre Julliard julliard(a)winehq.com

July 22, 2001