Hello everyone. I'm thinking about participating in the Google SOC 2007. Given that Wine in one of my favorite Open Source projects I find interesting the idea of implementing the DIBEngine. In the past I've worked in some Open Source projects, one of them QT-Win32 and also I did little contributions to the OFC (Open Foundation Class). I've experience with C coding, mostly from working on Educational OS like GeekOS and PintOS.
From what I understood the hard part of this project is INTEGRATION. I mean integrating the new code into the Wine repository without breaking everything? Am I right?
About the drawing code, I read that is possible to use the X11 code, also the ReactOS code and the old Transgaming DIBEngine (incomplete). Is that correct? Waiting for your comments and ideas. Regards, Ivan
Am Montag 05 März 2007 21:35 schrieb Ivan de Jesus Deras Tabora:
Hello everyone.
I'm thinking about participating in the Google SOC 2007. Given that Wine in one of my favorite Open Source projects I find interesting the idea of implementing the DIBEngine. In the past I've worked in some Open Source projects, one of them QT-Win32 and also I did little contributions to the OFC (Open Foundation Class). I've experience with C coding, mostly from working on Educational OS like GeekOS and PintOS. Great!
About the drawing code, I read that is possible to use the X11 code, also the ReactOS code and the old Transgaming DIBEngine (incomplete). Is that correct? I think ReactOS is not legally safe, but IANAL.
Ivan de Jesus Deras Tabora [mailto:ideras(a)gmail.com] wrote: Welcome here, Ivan!
From what I understood the hard part of this project is INTEGRATION. I mean integrating the new code into the Wine repository without breaking everything? Am I right?
Yes this will be a challenge and it is not about not breaking EVERYTHING but actually ANYTHING! :-) The best person to mentor that would be probably Alexander but I think he said he found this not a good SoC project.
About the drawing code, I read that is possible to use the X11 code, also the ReactOS code and the old Transgaming DIBEngine (incomplete).
X11 is certainly possible but would need quite some love as it is not exactly known for readibility. ReactOS you better don't mention here in Wine. As long as ReactOS has not been fully audited from an independent organization to not contain any copied code not under a compatible open source license, Wine will not accept any code that looks or even has the slightest suspicion that it might be from ReactOS. That would IMO only explicitedly exclude the code for the automatically code generated files for the optimalized DIB operations from Ge van Geldorp, which he states he did develop all on his own and can't be copied since Microsoft does not do it in such a way. And then you would need to get them from him and not the ReactOS tree. He said he was ok with them being used in Wine. The Transgaming DIB engine is a start but is still far from complete. And I personally don't think it should be done in the X11 driver as that will require to do the same work in the quartz driver again and any other graphics display driver that may come up in the future. Basically it will be unmaintainable once there is more than one possible display driver in Wine. Rolf Kalbermatter
On 05.03.2007 22:57, Rolf Kalbermatter wrote:
ReactOS you better don't mention here in Wine. As long as ReactOS has not been fully audited from an independent organization to not contain any copied code not under a compatible open source license, Wine will not accept any code that looks or even has the slightest suspicion that it might be from ReactOS.
BTW, has the Wine code audit ever been finished or was it just aborted when media attention faded? The last statement I found was from Alexandre in March 2006 where he stated that 50% of the code were covered. Regards, Carl-Daniel
BTW, has the Wine code audit ever been finished or was it just aborted when media attention faded? The last statement I found was from Alexandre in March 2006 where he stated that 50% of the code were covered.
The code audit continues. However, the SFLC has turned its attention to building a set of tools to make it easier to automate the audit, and to drive for 100% coverage. The first prototypes are done, now it's just a matter of setting up web servers and infrastructure and getting the kinks out. So, in short, it is ongoing, if slowly. Cheers, Jeremy
participants (5)
-
Carl-Daniel Hailfinger -
Ivan de Jesus Deras Tabora -
Jeremy White -
Rolf Kalbermatter -
Stefan Dösinger