- Wine-devel - list.winehq.org

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

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

22 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

Wine doesn't seem to like TrueType fonts.
by David Hagood 21 Jul '01

21 Jul '01

Has anybody else seen this behavior: I have a directory of TrueType fonts that I can point xfs to. When I have that directory in the fontlist, wine ALWAYS regenerates the font cache on every start (thus slowing Wine down immensely). Remove the TrueType directory from the font table, and all is well: Wine will regenerate the font cache once, and then use the font cache from there on.

1 0

Marshaling
by Daniel Walker 21 Jul '01

21 Jul '01

From what I've read when someone creates a custom interface for COM, an IDL file is generated, then the MIDL compiler uses the IDL file to create proxy and stub code that works with the standard COM RPC functionality.. So under some (most) circumstances wine's COM implementation would only have to facilitate the sending and recieving of the marshaled data .. Not to minimize the work involved .. The standard marshaling would have to do all the generic COM interfaces like IUnknown, IStorage, IStream (I think). Even though full implementations of those would be available . But most components would have custom interfaces so they would also have their own marshaling code .. If I'm 100% correct then , I guess, there wouldn't be a need for the type information. Yet it exists .. Unless the type info is used for something other than marshaling. Daniel Walker

2 1

Re: more misc fixes
by Alexandre Julliard 20 Jul '01

20 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > OK. So what you really what is exactly the opposite of what I tried to do? Yep ;-) > You want all 16-bit exported function prototypes moved from the .h > files to the implementing .c file in all cases that is is possible (ie Wine > compiles without errors or warnings)? Exactly; but note that in most cases the prototype is not even needed at all. I don't want all 16-bit C files to start with a bunch of prototypes either, this would just be unnecessary duplication; only the functions that are actually called from elsewhere in the file should be prototyped IMO. > Do you also want the types and structures moved as well? > That will often not be possible, but do you want it > despite this in the cases where it is possible? Wherever possible it would be a good thing yes. -- Alexandre Julliard julliard(a)winehq.com

3 2

UNC
by Bill Medland 20 Jul '01

20 Jul '01

Is anyone doing anything on UNC filenames? (In particular I am interested in GetFileAttributes) Bill

2 1