- Wine-Devel - list.winehq.org

[PROBLEM REPORT] Edit control line scrolling
by Gerard Patel July 23, 2001

July 23, 2001

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 );

2 1

Why is this wrong?
by Bill Medland July 23, 2001

July 23, 2001

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

1 0

Re: Executable permissions on .exe/.com files
by Alexandre Julliard July 23, 2001

July 23, 2001

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

1 0

Re: implement BuildCommDCB16 using BuildCommDCB
by lawson_whitney＠juno.com July 23, 2001

July 23, 2001

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.

1 0

Still problems with snoop
by Uwe Bonnes July 23, 2001

July 23, 2001

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

2 2

Re: PATCH: msvcrt.ungetc
by Alexandre Julliard July 23, 2001

July 23, 2001

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

2 1

RE: Microsoft source code releases - a danger to Wine?
by Patrik Stridvall July 22, 2001

July 22, 2001

> There'a a legal doctrine whose name I can remember (I'm too young for > senior moments!) ... "inevitable contamination" or something It is call "inevitable disclosure" I think. > like that. > The basic idea is that someone who had been exposed to > Microsoft source > code and then worked on Wine within a given period of time would be > assumed to have used knowledge gained from that exposure. I believe > that the burden would be on that person or the Wine project to show > the opposite. For that person, perhaps. IIRC the doctrine of "inevitable disclosure" it on a little shaky ground as it is eventhough some Judges have use it so far, it is NOT 100% established doctrine. As far as the Wine project is concerned, you will have to stretch the doctrine pretty far since the Wine project can't possibly know what a patch submittor has done before unless he tells us himself. > This is what I'm really worried about. Some well-meaning hacker takes > "Advanced Operating System Theory" at a Microsoft-beholden university > and then makes a contribution to Wine. (The more I think about it, > I'm surprised Microsoft isn't trying harder to expose more people to > their code and license.) Sure, we probaly need to make others more aware of that, but that primarily concerns them, not us. > Fair use? We don't need stinking fair use! After all, that might > interfere with corporate earnings reports. (I'm too old to become a > communist!) And favouring fair use have what to do with communism? It is entirely possible to have a capitalistic society without Intellectuall Property (IP) at all or with very weak IP (strong fair use). > > That said, nothing I can see appears to restrict someone > who has accepted > > their license from answering explicit questions we might > have, so long as > > they are not doing so for hire (thus 'commercially'), and > so long as they > > don't distribute source code. A fair bit of useful > knowledge might be > > gained in that way, albeit slowly. > > > > > Now you're really scaring me! Why? Any violation is primarily their problem and extending derived work over a verbal description is stretching far to far. This has already been established by actual court case.

2 1

RE: Microsoft source code releases - a danger to Wine?
by Patrik Stridvall July 22, 2001

July 22, 2001

> > Worse yet: If we coincidentally use similar code to theirs, > how can we > > prove we haven't looked at their code? If I were paranoid, > I'd say the > > single purpose of releasing the source was to get wine in trouble. > > It's not paranoia when they really are out to get you! Perhaps not, but do you really have proof that they are out to get you? :-) Seriously, I think you should calm down, getting to upset will do you no good. > IANAL, but distribution has been limited enough to this point > that they > would probably have to show some plausible manner in which > the exposure > could have occured. That's why I think wider distribution increases > the vigilance required. The burden of proof is still on Microsoft, not us.

1 0

RE: Microsoft source code releases - a danger to Wine?
by Patrik Stridvall July 22, 2001

July 22, 2001

> On Sat, 21 Jul 2001, Ian Pilcher wrote: > > > This leads me to wonder if anyone's ever thought of taking steps to > > protect Wine from "contamination" by Microsoft IP (legally, > not tech- > > nically :-). > > What can we do about that? Since none of the people involved > is going to > have a look at the actual M$ source, how are we supposed to know if a > patch posted on the list is taken from them? We can't and we don't have to. The burden of proof is on Microsoft. Of course it is a civil cases and the proof need only be on preponderence of evidence but it still their burden primarily. > Worse yet: If we coincidentally use similar code to theirs, how can we > prove we haven't looked at their code? If I were paranoid, I'd say the > single purpose of releasing the source was to get wine in trouble. First of all: We know who submitted a patch since that information is in the CVS log, so unless they can prove that Alexandre should have realized the person submitting the patch, submitted code not copyrighted by that person, the burden fall on that person and that person alone. If that person can't be identified through the e-mail adress to bad for Microsoft. If he can they will have to drag him to court, not the Wine project. Sure Microsoft probably can ask the Wine remove the offending code and sue us if we don't, but since we in fact also are a victim of the submitters misrepresentation I think any reasonable judge would: 1. Require that Microsoft prove that the code is theirs. This might be a little difficult without providing the actual code to the Wine project and requiring any developer of the Wine project to taint him self by signing a NDA with Microsoft would probably not required by the court. So the reasonable cause of action would for Microsoft to release the code without a license that could taint us or pay for an independent 3rd party to review and establish this. 2. Require that Microsoft provide a patch to remove the offending code from the current CVS. Note that we also are a victim so requiring more would probably be considered unreasonable. Why should we pay for (in money or effort) somebody elses crime or legal liabillity against Microsoft. All in all I think the Judge would be rather annoyed that Microsoft didn't try to solve this problem without him. In short, while IANAL, if Microsoft (or somebody) feels that some code in the CVS is copyrighted by them we should simple require that. 1. Prove it to us, without any risk of taint, or to some independent 3rd party at their expense. 2. Provide a patch against the current CVS that removes the offending code preferable made by the same 3rd party as above at their expense. 3. Require that the 3rd party sign a statement under perjury that the patch removes the offending code and only the offending code. Remember we are also a victim under such an event and requiring more would probably not be look on favourable by the courts.

1 0

Proposed config file change
by Andreas Mohr July 21, 2001

July 21, 2001

Hi all, I've been thinking for a rather long while now that the config file has a rather poor format. Several settings are pretty misplaced, and it tends to get chaotic. Let me just suggest something different: [COMM\\ParallelPorts] "Lpt1" = "..." "ppdev_378" = "..." [COMM\\SerialPorts] [COMM\\RASAPI] [COMM\\TAPI] [COMM\\WININET] [COMM\\WINSOCK] [DLLs\\Overrides] [File\\Drive x] [File\\General] "Windows" = "..." "System" = "..." "Temp" = "..." "Path" = "..." "ShowDirSymlinks" = "..." [File\\Registry] "LoadGlobalRegistryFiles" = "Y" "LoadHomeRegistryFiles" = "Y" "LoadWindowsRegistryFiles" = "Y" "WritetoHomeRegistryFiles" = "Y" "SaveOnlyUpdatedKeys" = "Y" "Profile" = "c:\\windows\\Profiles\\Administrator" [Graphics] "GraphicsDriver" = "x11drv" "WineLook" = "Win95" [Graphics\\DirectX] [Graphics\\Fonts] ;See a couple of examples for russian users below "Resolution" = "96" "Default" = "-adobe-helvetica-" "DefaultFixed" = "fixed" "DefaultSerif" = "-adobe-times-" "DefaultSansSerif" = "-adobe-helvetica-" [Graphics\\OpenGL] [Graphics\\Printing\\afmdirs] [Graphics\\Printing\\Spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [Graphics\\Screen\\ttydrv] ;"Drivers" = "tty" ;"XtermProg" = "nxterm" ;"InitialRows" = "25" ;"InitialColumns" = "80" ;"TerminalType" = "nxterm" [Graphics\\Screen\\x11drv] ... [Sound\\DSOUND] "EmulatedDriver" = "..." [Sound\\WinMM] "Drivers" = "wineoss.drv" "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" [wine] "ShellLinker" = "wineshelllink" [wine\\Clipboard] "ClearAllSelections" = "0" "PersistentSelection" = "1" [wine\\Ports] ;"read" = "0x779,0x379,0x280-0x2a0" ; "write" = "0x779,0x379,0x280-0x2a0" [wine\\Spy] "Exclude" = "WM_SIZE;WM_TIMER;" This has the advantage that it has a very basic structure (COMM, DLLs, File, Sound, Wine), and you always know where to start searching. I haven't spent much thought on whether it's really "right" and, most importantly, extensible, though. Comments ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0