September 2006 - Wine-Devel

Re: LPGL functions in Reactos that are stub in Wine

by Dan Kegel

On 9/4/06, Brandon Mark Turner <turnerb7(a)msu.edu> wrote: > I think it would be nice if everyone just left this thread alone for now. > You guys made up your minds that you don't want our patches. And thats > fine. But there is no reason to continue to express hateful opinions > about ReactOS. I don't hate ReactOS at all. I hope they get their audit completed and verified by a group like the SFLC soon. In the meantime, I hope they can benefit from merging in code from Wine, and I hope they reciprocate by filing bug reports against Wine as they find missing features & apps that need them. - Dan

Sept. 4, 2006

Re: LPGL functions in Reactos that are stub in Wine

by Brandon Mark Turner

Dan Kegel writes: > I doubt the audit is completed yet (these things are asymptotic; you > can get to 90% > complete a lot faster than 99% complete, etc.). I am not trying to be a jerk and I am not taking a shot at you personally. I actually think you are a good guy Dan so don't take this the wrong way. To quote you earlier, you said "The audit went awfully quickly, for one thing," referring to the ReactOS audit. The ReactOS audit is 95.3% done currently. The last few percent is going to take a long time because that is where any tainted code, _if_ there is any in the tree, is located. So I would say both audits are going to take the close to the same amount of time. Not only that, but both of them will be carried out in the same time frame where the first ~90% went fast and the last part went slow. But somehow the ReactOS is discredited because it went 'quickly'? I just want to know why you guys are the first ones out the door yelling about how we suck. ReactOS devs for the most part don't have anything bad to say about you guys or your project. But you guys seem to want make us look so bad and it is kinda depressing. Not accepting our patches based on policy is one thing, but just talking trash about us publicly is another thing. I think it would be nice if everyone just left this thread alone for now. You guys made up your minds that you don't want our patches. And thats fine. But there is no reason to continue to express hateful opinions about ReactOS. Brandon

Sept. 4, 2006

Re: LPGL functions in Reactos that are stub in Wine

by Dan Kegel

On 9/4/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > BTW, can results of Wine's own audit process be seen somewhere on the web? Good question. I don't know the answer, but I'll see if I can find one. > It would be nice to know at least what speed was Wine project audited and > when did it happen? How did it influence Wine code size? Here's a timeline of sorts: in Feb 2005, Wine started thinking about these issues and about contacting the SFLC: http://www.winehq.org/pipermail/wine-devel/2005-February/033437.html By May 2005, Wine was indeed getting involved with the SFLC: http://www.winehq.com/?issue=274#News:%20Software%20Freedom%20Law%20Center In April 2006, there was an announcement about an audit already underway: http://www.winehq.com/?issue=310#Software%20Freedom%20Law%20Center%20Update I doubt the audit is completed yet (these things are asymptotic; you can get to 90% complete a lot faster than 99% complete, etc.). So it's taken Wine something like 16 months so far. Hope that helps. - Dan

Sept. 4, 2006

Re: LPGL functions in Reactos that are stub in Wine

by Saulius Krasuckas

* On Mon, 4 Sep 2006, Dan Kegel wrote: > * On 9/4/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > have you any proof of "all ReactOS code audit process being fake" ? > > The audit went awfully quickly, for one thing, > and it was done without a neutral third party. > Wine's been doing its own audit with the help of > the Software Freedom Law Center. If ReactOS > worked with those folks, we'd trust the audit > results more. Well, thanks. > > I very well believe some parts of their code may be dirty, but then > > please pinpoint this. Otherwise you sound like sentencing ReactOS to > > death even w/o taking a precise look at it :( > > I'm afraid it's the other way around at this > point - the burden of proof is on ReactOS to show > that their code is clean :-( Now that you have stated Wine already has been through some audit process, this is pretty clear. This is something I wanted to hear, thank you Dan. BTW, can results of Wine's own audit process be seen somewhere on the web? It would be nice to know at least what speed was Wine project audited and when did it happen? How did it influence Wine code size? I seem to be missing this info for some reason :(

Sept. 4, 2006

Re: LPGL functions in Reactos that are stub in Wine

by hippy hip

> I'm afraid it's the other way around at this > point - the burden of proof is on ReactOS to show > that their code is clean :-( A)-no offense, but this sounds like something SCO would say. if you got something (from reactOS current that is already audited..) that you can prove is dirty- please due so. people need facts. > Until ReactOS has been given a clean bill of > health by an outside auditor, ReactOS developers > are fairly restricted in how they can help Wine; > posting bug reports against Wine may be about the > best they can do. > - Dan B) i agree with the outside auditor thing. at least before final version comes out. what they're doing is 'fringe' enough that they need to be able to back up the 'cleanness' of their code in a major way. though i do for one believe their internal audit is real- but i agree an outside audit at some time would be much better. C) if wine's offical policy on reactos is to not except contributions from them until a complete audit is done on them by an outside source- that's fine. pretty hardline- but absolutely fine. though- there is a difference between making accusations & having a policy. the first ends up dragging reactos' name through the mud, & -in turn, if they get a clean bill of health will end up dragging wine's name though the mud & will not do anyone any good in the end. the second protects everyone and leaves room for a future. both wine & reactos are great projects & if done correctly will have a huge impact on things in the future. but the direction these conversation seem to be taking doesn't help anyone. i think you just need a policy. (cheerleading all the way... lol) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Sept. 4, 2006

Re: LPGL functions in Reactos that are stub in Wine

by Dan Kegel

On 9/4/06, Julien <julienc(a)psychologie-fr.org> wrote: > Sorry Mike but from an external point of view your argument sounds like > ideology: > 1) I dont understand why someone contributing to ReactOS would have > his/her code rejected in all cases. Contributing to ReactOS does not > necessary means the code is "dirty" reverse engineering. > > 2) The author stressed he did not develop this code by any reverse > engineering. The thing is, we just don't trust the ReactOS folks at the moment. Perhaps if they can get the SFLC to bless their audit, we could trust them again. The stakes are pretty high; if we include code, and it's later shown to be tainted, the whole project could be endangered. We can get along pretty well without any code from ReactOS, so we probably should. Risking the project for the sake of getting a few functions just doesn't seem worth it. We're very happy to let ReactOS use Wine code, though, there's no problem with that. - Dan

Sept. 4, 2006

Re: LPGL functions in Reactos that are stub in Wine

by Dan Kegel

On 9/4/06, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > Well, Dmitry and Mike, this sound very probable, but have you any proof of > "all ReactOS code audit process being fake" ? The audit went awfully quickly, for one thing, and it was done without a neutral third party. Wine's been doing its own audit with the help of the Software Freedom Law Center. If ReactOS worked with those folks, we'd trust the audit results more. > I very well believe some parts of their code may be dirty, but then please > pinpoint this. Otherwise you sound like sentencing ReactOS to death even > w/o taking a precise look at it :( I'm afraid it's the other way around at this point - the burden of proof is on ReactOS to show that their code is clean :-( > IMHO the dirty parts are to be moved or are already moved to the TinyKRNL > project, no? I wouldn't know about that. Until ReactOS has been given a clean bill of health by an outside auditor, ReactOS developers are fairly restricted in how they can help Wine; posting bug reports against Wine may be about the best they can do. - Dan

Sept. 4, 2006

Re: LPGL functions in Reactos that are stub in Wine

by Julien

Sorry Mike but from an external point of view your argument sounds like ideology: 1) I dont understand why someone contributing to ReactOS would have his/her code rejected in all cases. Contributing to ReactOS does not necessary means the code is "dirty" reverse engineering. 2) The author stressed he did not develop this code by any reverse engineering. Now I have two questions: How is it possible to consider rejecting the code without even looking or commenting the patches? Why do you base your argument on ideology and not on facts? What is the point of having another Wine contributor to reimplement the exact same code, rediscover the exact same stuff? The setupapi patches are perhaps incomplete, perhaps the format of the patches are not perfect but rejecting the patches because the author is @reactos.org seems uncorrect. Best, Julien (wannabe wine hacker)

Sept. 4, 2006

Re: LPGL functions in Reactos that are stub in Wine

by Saulius Krasuckas

* On Mon, 4 Sep 2006, Dmitry Timoshkov wrote: > * "Tom Wickline" <twickline(a)gmail.com> wrote: > > Looks to me like reverse engineered code is "not permitted for > > inclusion in ReactOS" so how is it there participating in "dirty" > > reverse engineering? > > That's just a declaration supposed to create a better face on public, > nothing more to take it seriously. Same thing about auditing IMO. Well, Dmitry and Mike, this sound very probable, but have you any proof of "all ReactOS code audit process being fake" ? I very well believe some parts of their code may be dirty, but then please pinpoint this. Otherwise you sound like sentencing ReactOS to death even w/o taking a precise look at it :( IMHO the dirty parts are to be moved or are already moved to the TinyKRNL project, no?

Sept. 4, 2006

Re: wined3d: Avoid crashing when ProcessVertices is called with NULL vertex declaration

by Stefan Dösinger

Hi, > I don't understand what the code does but every part of it depends on > having a non-NULL SrcImpl. I think screaming bloody murder but continuing > is better than crashing. > > I agree that the code doesn't look good but at least testing can proceed > past this point. For some reason I didn't get that patch, but from consulting the msdn documentation for IDirect3DDevice9::ProcessVertices it looks like ProcessVertices is a bit wrong. It doesn't get a Vertex buffer as in argument, instead it gets a vertex declaration. Furthermore our processvertices implementation doesn't handle vertex shaders. The msdn page doesn't state explicitly, but I think if the vertex declaration is NULL either the current declaration in the device should be used, or D3DERR_INVALIDCALL returned. This should preferably be tested with a unit test. I was the one who implemented ProcessVertices, but I only implemented it for Direct3D7 applications, and it is only tested with Half-Life 1 and Anarchy Online. It should work for d3d8 and d3d9 apps with the fixed function pipeline, but not with shaders.

Sept. 4, 2006