Mention of ReactOS in WineHQ forum

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Posts: 190
Joined: Thu Jan 24, 2008 3:52 pm
Location: GMT +1

Post by SdC » Thu Feb 28, 2008 12:33 pm

I'll get back to you with some suggestions and examples on expanding the Wiki, need some time to work it out.
And libel is libel...
Yes but who can afford to take the risk and expense of a lawsuit.....

Posts: 11
Joined: Wed Feb 27, 2008 10:43 pm

Post by _Russell_ » Thu Feb 28, 2008 12:56 pm

SdC wrote:I'll get back to you with some suggestions and examples on expanding the Wiki, need some time to work it out.
And libel is libel...
Yes but who can afford to take the risk and expense of a lawsuit.....

Support the "Ban the chev" campaign today!

Posts: 147
Joined: Sat Dec 18, 2004 10:12 am

Post by Wierd » Fri Feb 29, 2008 2:57 am

Sadly, Reactos has had problems of this sort for a VERY long time, and Wine was suspicious of us for a long time before the bombshell dropped that induced the audit.

(Those problems being that people dont want attention being taken away from their linux based projects, who feel that FOSS == Linux, and nothing else.)

After the bombshell fell and exploded, WINE considers ReactOS contaminated, or something. Nevermind that not a single scrap of evidence to support the allegation has been presented to date.

I can understand why WINE would want to keep its reputation clean from the mudslingers, but on the other hand, I find the behavior preposterous at the same time.

Posts: 136
Joined: Sat Jun 17, 2006 4:42 pm

Post by Speedator » Fri Feb 29, 2008 4:51 pm

We probably need a broad dialoque between Reactos and Wine crew about the problems. So today the cooperation is more like Reactos looks what Wine progressed and tries to use it for their project, isn't it? So if those differences are gone, both teams may work together in some points. Means Wine also accepts code and documentations from ReactOS-Coders and so both teams may write those code and docs in cooperation.
But someone need to start this probelm-dialoque.

Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm

Post by Z98 » Fri Feb 29, 2008 6:07 pm

The "problem" between ROS and Wine isn't as serious as you guys seem to think. The people that count in the Wine hierarchy have a far better grasp of the legal standing of ROS than some random guy who thinks that headers are copyrightable. So all I can say is, stop worrying about all this.

Posts: 223
Joined: Thu Sep 29, 2005 3:00 pm

Post by jimtabor » Sat Mar 01, 2008 2:39 am

I reviewed the rest of the ntoskrnl svn logs. Everything looks like normal evolution of changes. Trouble-shooting and debug testing generated changes to the code and known information from outside sources, this includes SDK/WDK, books and web sites (not based on leaked src).

Consider the source, it does read like another SCO type argument all based on not doing the proper research. I consider this a closed issue. Next time don't wait and poo poo any assertions away. Let me know about them so I can research it and verify the problem.

I knew back in 2004 something strange was going on when a team of MS agents showed up to look for the leaked source in January a month before the known February leak. Then finding out what it was all about. Now anyone from that side can say, it was all based on the leaked source. With out the logs, anyone not knowing the history of the project can assert anything and it could stick. I told you all this was coming!


Posts: 136
Joined: Sat Jun 17, 2006 4:42 pm

Post by Speedator » Sat Mar 01, 2008 11:46 pm

Z98: So if there is no problem, why reactos-code is not allowed in wine, explained copyright-problems? :?
Anyway I hope the cooperation will be successful in future ;)

Posts: 926
Joined: Tue Nov 30, 2004 10:26 am
Location: Sweden

Post by GreatLord » Sat Mar 01, 2008 11:54 pm

wine accpect patcher from us.

the issue is they way wine taken and the way reactos takes
wine is made for linux
reactos is made for nt archture

the issue is we need more advance way todo thing and more simluare way as windows nt archture doing stuff. and wine take a simple way and reuse stuff that comes with linux kernel.

we need more advance shell32 and wine does not need a extream advance shell32 and we need it working exackly as windows, even some undocs behoirs. here does wine and reactos are not agreed how thing should be done, wine does not allown the undocs stuff if u can not found a 3d party program using it. and reactos does not care if a thrid party program using it or not, we implement the undocs behoirs for our new explore that are finish are using the undocs behoirs.

so most of code for shell32.dll are not send to wine. only few thing that we found we both have a seruies bugs or missing implemented that is

wine or reactos does not have any issue betwin us.

Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Sun Mar 02, 2008 2:28 am

I will expand a bit from the wine side. Wine side has a few very careful developers. Since there is a commercial operating company behind wine lot of care is taken to make sure copyrights are correct.

Few patches have bounced out of wine from Reactos because people did not state license right give the appearance that wine would not accept Reactos patches. Some of the bad introductions I have seen is this is from Reactos please look at following patch. Yep failure AJ wine maintainer looks at it and skips straight over it because basically he does not have time to work out if license is correct. Now if it was stated something like this code was patched to lgpl section in reactos from wine and is still LGPL. It gets looked at.

Others patches have bounced threw the normal AJ quality control. Yes it can take up to 12 submits of a patch to get it to AJ quality level. Or some cases it bounces completely out because the patch is in the wrong place and is a breach of the wine no hacking to work rule.

Any import from a external project into wine need to state its license and be a compatible license with wine as policy. So this bouncing of patches was like status normal. Also wanting to know source of information is also status normal.

Also if something was imported into Reactos from a external project wine would kinda expect the external project check to make sure it is not going to get them into trouble.

There were a few mirror errors in Reactos that were fixed threw the Audit. All the errors I saw were from third party imports that were never put up to the wine tree. Also when traced back 100 percent legally sound. Just some of the hot heads in wine have not got trust 100 percent back in Reactos to equal to any other external project yet. Also did not help that a few legally foolish people out there bashed them up as important when they were not really when fully investigated. Just because something should have the words Microsoft on it does not make it toxic. License on them was basically Microsoft closest license to BSD. 100 percent usable in lgpl and gpl programs. Its incompatible license that makes stuff toxic.

Where the mistake of taint came from is funny really. Same files that were released to assist windows and dos development by Microsoft under a really open license was also in MS leaked NT source code. Files in Reactos were acquired from a source back in the 19xx before the windows source leak ever happened. People forgot to time line. Anyone who thinks they have found bad code in Reactos please back trace it first so you don't make a idiot out of yourself.

Then there are a few idiots like Z98 said pointing to header files and other things on top. Then we had some anti Microsoft people as well what say if it has a Microsoft name on it you cannot use it even if the copyright permits it.

Most of the wine guys know this and kinda accept it as o well stack of errors happened.

Also some of the old allowed development methods in reactos were in conflict with wine rules. Current Reactos rules are in alignment.

Basically the issue is dead just taking a long time to die. Its more about trust of some people around wine than any real facts now.

Note to GreatLord wine rules are a little funny. Once ros explore is using the undocumented features they can be requested in wine because 1 application is using them.

In the past before wine tighted up the rules people would just create test cases of undocumented operations and add them to wine. Wine is trying to focus on application needed functions first and stuff with a legal source and reason.

Post Reply

Who is online

Users browsing this forum: DotBot [Crawler] and 3 guests