- Wine-Devel - list.winehq.org

Re: Visual FoxPro 5 apps
by Rick Romero Dec. 21, 2001

Dec. 21, 2001

I just noticed that my Foxpro 5 post is on WWN, so I thought I'd share the thread from the wine-users list... Rick On 5 Dec 2001 at 13:34, Rick Romero wrote: > On Wed, 2001-12-05 at 13:22, gerard patel wrote: > > On 05 Dec 2001 11:55:10 -0600, Rick Romero <rick(a)valeoinc.com> wrote: > > > > <snip window problems> > > > > >Now I've tried a few different distro's, and quite a few different > > >releases of wine (been compiling from cvs for the last couple months), > > >so I don't think it's just me... BUT. > > > > Try with Wine from 01 june 2001. > > Huge changes have caused several severe regressions > > after this date and they are mostly unfixed. > > Well, I downloaded Wine-20010510, and the MDI windows work PERFECTLY. > They're highlighted blue when active > The scrollbars work > The mouse click is released. > > Although overall, it doesn't work near as well.. > > > > > If your app has the same glitches with Wine as of 01 june > > 2001, its problems are not related to the general regression. > > In this case try to do this, I'll take a look. > > In the other case, it's unnecessary as I'm already aware of > > these problems. > > If I'm not imposing too much, could you point me in the right direction? > > I don't know if I could come up with anything of 'acceptable patch > quality', but I'd like to try. > > Is the problem in mdi.c? > If it was only a simple bug, I'll have it killed since a long time. I'm mostly in the dark, but I think it's more the progressive passage to a whole new design that has caused a string of regressions. Gerard ----- Valeo, Inc. will be closed for the Holiday season starting on December 20, 2001 through January 1, 2002 resuming business on January 2, 2002. We wish you a Happy Holiday Season! -- Rick Romero IT Manager Valeo, Inc. ph 262.695.4841 fax 262.695.4850 rick(a)valeoinc.com

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> On Fri, 21 Dec 2001, Patrik Stridvall wrote: > > > There are many thing that are important in the world not just one, > > so it was just a reaction of your persistance that the spirit of > > something is the only thing that matters. > > I focused on the spirit to put some sense in the discussion, > go get to the > point where we agree to disagree, but you don't seem to want that. > > In computers we have interfaces and implementations. It's healthy to > separate the two. Yes, but this doesn't mean that this is always possible. > In our case, the interface is the spirit of > the LGPL, > while the implementation is the LGPL itself. > > If there are 'Gapping Holes' anywhere, they are in your > arguments. You say > you agree with the interface, but you disagree violently with the > implementation. On the other hand, when I ask you for a different > implementation, you can't it can not be done. I say that it can't be done without having a copyright law that will be unacceptable in other ways. > Patrik, you > can not agree > with an unimplementable interface, for crying out loud!!! You > have to make > up your mind and choose! I would very much like to have "Peace on earth", but I don't think it every will be "Peace on earth". You can call that illogical if you wish. It is up to you.

1 0

license discussions
by Marcus Meissner Dec. 21, 2001

Dec. 21, 2001

Hi, Could we please create a new mailing list wine-license, where all the people who care about licenses can discuss them? Ciao, Marcus

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > Does it nessararily follow that you wish to accept any means to > > achieve this? Including, say, to be really extreme: > > "Nuke the middle east, then it will be peace there" > > and after enough nukes it probably WILL be peace, > > so it would be entire in line with peace on earth. Right? > > Patrik, if you think licensing software under the LGPL is > equivalent to > nuking the middle east out of existence, you need to take a _deep_ > breath, drink some cold water, and stay away from those pills. > > Since we're here, this is the type of attitude that really > destroys the > credibility of much of your arguments. It was purposely extreme to illustrate that you can fullfill the spirit of something good with very bad results. There are many thing that are important in the world not just one, so it was just a reaction of your persistance that the spirit of something is the only thing that matters. > I mean, exagerations > of the form: > 'LGPL gives you nothing, it's a pile of crap' despite the > enormous effort > put in it by various lawyers and law professors from reputable > universities, will not buy you many friends. Do you really > think that the > entire law establishment in the US has all gone mad and can't see the > 'Gapping Hole' in the LGPL, and you were the chosen one to see it? I'm sure they all have worked very hard, however as in the extreme example above, all means to achieve something is not nessarily good, if seen as a whole. The meant this time is the doctrine of derived work, which since it is one of the few means they got it was naturely the choice. However, a to strong doctrine of derived work, is not good from other points of views so it will be entirely possibly that the courts will not rule in their favour.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > No, its not irrelevant because it will effect the advise the company > > lawyers give their clients. > > But know you are inconsistent with yourself. You've been > claiming that it > is the very spirit of the LGPL that would scare companies > away, and I can > see some merit to that idea. No, I have been say that the _means_ to implement the spirit of LGPL might scare away companies. > You've also been claiming that > the LGPL may > not be enforceable, thus in mathematical terms, > the expected value of the LGPL < the intended meaning of the LGPL > it follow directly, that the more you are right, the less negative the > advise of the lawyers. Only if lawyers have certain mathematical properties, which they certainly do not have. Actual most functions don't have such properties either. > So, if you 100% right, the LGPL would become BSD, and the > lawyers would > give the same advise, as for the BSD. If you are 100% wrong, > then we do > get the full protection of the LGPL, and we're happy. > Anything in between > is a linear combination of the two. In any case, there really > is no point > about bitching the doctrine of derived work. QED. LGPL can only be BSD if the doctrine of derived work is very weak, so it does have something to do with that. > In fact, choosing the LGPL is a very nice way of hedging our > bets agains > future changes in copyright law. And this is so because of > the negative > feedback loop that the LGPL introduces agains the copyright > law. Brilliant. Now you are contradicting your self. You said earlier IIRC something about that you shouldn't believe that the license Wine chooses effect copyright law.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> On Thu, 20 Dec 2001, Patrik Stridvall wrote: > > > Sure it is true that what people (read: companies) believe > is true is > > more important than what really is true. > > So, in fact, you indirctly agree that arguing about the doctrine of > derived work as part of this discussion is irrelevant. No, its not irrelevant because it will effect the advise the company lawyers give their clients. You seem to wish to use ignorance (or uncertainty) as weapon to protect Wine, but know this: Ignorance (or uncertainty) cuts both ways. Gav has said that Transgaming or for that matter Corel would have use Wine if it had been LGPL:ed. Perhaps this was because of ignorance, perhaps not. Anyway even if you would be able to convince Gav that he was/is wrong, you must realize that Gav IIRC have researched legallity issues extensively so it is entirely likely that somebody else spending similar resources would come to the same, in your opinion wrong, conclusion. In short: Ignorance (or uncertainty) is a dangerous weapon. > All you seem to be saying is that you think that the _spirit_ > of the LGPL > would be detrimental to Wine since it will drive companies away. > > Right? No. I have been trying to explain just because to are for the spirit of something it is not nessarily so that you support all possible means to acheive something and sometimes any acceptable means to acheive something might not exists. Do you support the spirit of: "Peace on earth!" Does it nessararily follow that you wish to accept any means to achieve this? Including, say, to be really extreme: "Nuke the middle east, then it will be peace there" and after enough nukes it probably WILL be peace, so it would be entire in line with peace on earth. Right?

2 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall Dec. 21, 2001

Dec. 21, 2001

> Patrik Stridvall <ps(a)leissner.se> writes: > > > But why should I do that? > > I can for example write a script that download Wine for the > end user user > > and apply the patch automatically. > > The patch would be considered a derivative work, so distributing it > would also violate the LGPL. That again is dependent of the doctrine of derived work have any meaning since the patch is written by me and only contains my work. Just because you build upon somebody else work doesn't mean it is a derivation. Anyway since it denies my right to speech it must be constitional within the context of the first amendment which is IMHO very unlikely that a strong doctrine of derived work is. The copyright clause exception only reserves only gives congress the right to give exclusive rights to _their_ work not to the work of others (read: me). Note by patch I do not nessarily mean a patch like (diff -u) that contains the (LGPL:ed) context of the patch. An "ed-script" or whatever similar will do. Anyway the LGPL:ed context of a (diff -u) patch might very well be consider fair use so that might not be relevant.

4 4

Re: CryptoAPI (no, this has nothing to do with licensing! YAY!)
by David Elliott Dec. 21, 2001

Dec. 21, 2001

On 2001.12.20 11:52 Travis Michielsen wrote: [BIG SNIP] > Actually I too, have been hacking away at the CryptoAPI (advapi32.dll) > and > was going to submit a full patch for it at the end of the week. My > patch, > however, has almost a completely different approach to the problem! > Attached is my version (not quite complete or clean). > > These are the main differences and issues I see between our patches: > > 1) I can successfully acquire/release a context (tested with MSDN sample > code). I have not experienced any problems with <loading> a CSP. Umm, yes, I can successfully acquire and release when testing with the MSDN sample as well, but not with RSAENH.DLL that IE wants. > 2) Currently the ms CSPs can perform but all launch pstores.exe - the > protected stores service. This is fine except that it eventually crashes > > with an unhandled exception c0000005 and then becomes unwilling to start > again. Pardon my ignorance, but I didn't realize that that was what pstores did. > 3) Dependancy functions of pstores and M$ providers not implemented: > (advapi:RevertToSelf, ntdll:NtOpenProcessToken, advapi:SetThreadToken, > mpr:WNetGetCachedPassword, etc.) Yup, if pstores is necessary, we'll need pstores working, so that's something to add to the task list. > 4) I do not create any list of providers. This should not be required as > the > registry is supposed to contain the list of available providers. Once a > handle is acquired then we can gain access to the provider by this > handle. > Note: Key and hash objects need to link to the provider handle, when they > are > created. As for the key and hash: Yes, I am well aware of this, there is a blatant FIXME in the code since I haven't gotten there yet. And I don't know where you get that I am making a list of all CSPs. What I am doing is making a list of any CSPs which are in use and storing the appropriate function pointers in that object. I could simply do a loadlibrary each time the CSP is loaded and store all of that information for every context. But I thought it would be better to do it the way I did so that if multiple contexts are acquired from the same provider we don't have duplicate information in memory. > 5) I have not yet considered thread or process safing/locking. Nor have I > > done any reference counting. Well, I am not so sure about my thread safety but I think theoretically it is okay. I wrote the thread safety in from the beginning. > 6) Seting and getting Key/Hash/Prov Params doesn't consider flags not > used by > the CSP and have meaning in advapi32.dll. Haven't even really gotten that far yet. > 7) I currently do not allow a CSP to drop any of the stardard functions. > > This only affects a few functions, however, as MSDN states these > functions > are *required* for the CSP to have. If they are not implemented they > must > set the last error as ERROR_CALL_NOT_IMPLEMENTED. Well, CSP.DLL from the CSPDK does not provide a couple things. Originally I required every function to be provided but when I found that CSP.DLL did not provide one of them I decided to err the other way and only require the bare essentiallys like Acquire/ReleaseContext. > 8) You seem to make not use > ?????????? > Anyway I think the correct thing to do right now is to co-ordinate our > work > to make a single patch and implementation. > YES, definitely. Sorry to be stepping on your toes here. Most of the CryptAcquireContext function, specifically the parts that look up which CSP we need to load, I implemented rather quickly months ago. I didn't have time to do anything until a few days ago when I wrote everything else and posted it on wine-devel. > I am currently testing this code against windows 98. > Well, I have Win95osr2 running under Win4Lin and I use that as my C: drive in Wine as well. It works a lot better having everything stored on an ext2 drive than on vfat. I have not yet taken a look at your code but will do so as soon as I finish reading the rest of today's wine-devel. -Dave

1 0

Re: timed-out non-overlapped ReadFile
by Mike McCormack Dec. 21, 2001

Dec. 21, 2001

Hey Lawson, Cool. i just wanted to get apps like yours back to their working state. Ideally i need to add a bit more code for the case (ReadIntervalTimeout = -1) that waits until at least some data is received before returning.... more trouble :-) The timeouts for non overlapped ReadFile should help alot of the recent problems reported on wine-users... hopefully. Mike Original message from: lawson_whitney(a)juno.com .. >Sorry if that sounded like faint praise. The app works as well with >both patches as it did before with neither, and probably there is some >other app that needs non-overlapped ReadFile to time out. > >Thanks! > >Lawson ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: timed-out non-overlapped ReadFile
by lawson_whitney＠juno.com Dec. 21, 2001

Dec. 21, 2001

On Fri, 21 Dec 2001, Mike McCormack wrote: > > This patch handles the special case where > ReadIntervalTimeout=MAXDWORD, ReadTotalTimeoutConstant=0 and > ReadTotalTimeoutMultiplier=0 a little better. We should just wait > until we get some data, then read it and return in that case. > > Mike > > ChangeLog: > * handle ReadIntervalTimeout=MAXDWORD special case a bit better > Sorry if that sounded like faint praise. The app works as well with both patches as it did before with neither, and probably there is some other app that needs non-overlapped ReadFile to time out. Thanks! Lawson Slowly but with considerable uncertainty.

1 0