wine-devel

wine-devel@winehq.org

4 participants
84464 discussions

Why is this wrong?
by Bill Medland 23 Jul '01

23 Jul '01

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@+3$[#0H@(" @ M:68@*'!E<F9E8W0@/3T@+3$I#0H@(" @>PT*"4A+15D@:&ME>3L-"@EC:&%R M(&)U9F9E<ELR,%T[#0H)+RH@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@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@8G5F9F5R6S!=.PT* M(" @(" @(" @(" @(" @('!E<F9E8W0@/2 H8V@@/3T@)WDG('Q\(&-H(#T] M("=9)R!\?"!C:" ]/2 G="<@?'P@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 23 Jul '01

23 Jul '01

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 23 Jul '01

23 Jul '01

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 23 Jul '01

23 Jul '01

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 23 Jul '01

23 Jul '01

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 22 Jul '01

22 Jul '01

> 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 22 Jul '01

22 Jul '01

> > 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 22 Jul '01

22 Jul '01

> 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 21 Jul '01

21 Jul '01

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

Re: glibc bug mmap/malloc
by Alexandre Julliard 21 Jul '01

21 Jul '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > I mean, come on: why did they bother to implement malloc() at all > if the resulting architecture is THAT broken ? It's not broken, it just doesn't play well with programs like Wine that muck around with the process address space. But it's a perfectly reasonable (if not optimal) implementation for "normal" Unix apps. -- Alexandre Julliard julliard(a)winehq.com

2 1

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