Hi all,
I'm a student in Department of Mathematics, Sun Yat-sen University. My irc nick name is fracting, my real name is Qian Hong. I'm in GMT+8 time zone, availible on 10:00 to 18:00 (GMT+8) on #winehackers.
I know C/bash and some Linux skills. Currently I'm an intern in Redhat, working in the kernel-qe group.
I have great interesting in the Wine project. Last year I spent most of my spare time on reporting bugs to Wine. When I doing this I found lots of bugs regarding Chinese software have beem complained in local Linux forum for years but no one reported them to Wine project. In other words, I found most Chinese Linux users didn't report bugs to open source projects, well, I think that is a bug too :) After reported 100+ bugs, I'm surprised so many bugs have been fixed in just one year.
I wish I can do some more then reporting bugs for Wine project, great if I can get start with the 2012 GSoC and keep submitting patches to Wine after that. I have lots of ideas in my TODO list, unfortunately most of them might too hard to do as a GSoC project. Anyway, I'll post my ideas here, wait for feedbacks, choose one of them as my GSoC idea, and leave others as my job in the coming years. Certainly I'm glad to see any others working on those ideas :)
Here is my list:
- Implement ndis.sys
This idea come from the off-standard network authentication in China.
Lots of Universities in China using some off-standard network authentication methods for campus network connection, the authentication protocols are usually private and changed frequently, the authentication clients are usually Windows-only.
This issue is the main blocker for students in those Universities to change to Linux desktop or Mac. I've filed some bugs regarding some network authentication clients, such as [1],[2],[3],[4],[5]. However, even the above bugs are fixed, these clients might not work on wine because they depends on ndis.sys which is not implemented yet.
As an intern in Redhat network-qe group focus on NIC testing, I have great interesting in implement ndis.sys, though I think it is too hard for a GSoC project.
The ndiswrapper code is a great resource but not complete, also I known ReactOS project has a ndis.sys too but obviously it won't work on Wine.
Is it allowed to read ReactOS implementation to learn how things work? Anyway I'm interesting in what you think :)
- Implement/improve wpcap proxy
This idea is similar with the first one, in fact André H has already done the most important part [6],[7]. I hope André's patch will be accepted, and I'm interesting in improving it. I have done some proof-of-concept to show that some kinds of network auth client wich depends on winpcap will work on wine with André's patch.
- Improve builtin iexplore
This idea is come from another main blocker for using Linux/Mac in China. Most Chinese online banks are ie-only, depends on ActiveX and some ie-only style JavaScript or even VBScript.
Jacek and other wine developers has done lots of work on them, and I'm interesting in participating.
I've filed 40+ bugs regarding online bank support with Wine [8]. My goal is to make wine builtin iexplore works for as many online banks, currently I have more then 6 different online bank accounts for testing, guys in openbank-discuss group [9] will help on testing too.
- Improve USB support
Yeah, this might be another idea which is too hard for a GSoC project. We already have a third party patch, I wonder will Wine-1.6 have official USB support?
This idea is similar with the above one, my goal is to solve the online bank USB-key issues. After testing on 8 different USB-keys with the USB patch [10], I noticed they won't work on wine without hidusb.sys. ReactOS project has implement hidusb.sys in the last few months, again, is it allow to learn ReactOS code if I would like to contribute to Wine?
- Improve Wine CJK font support
The main idea is fix Bug 16325 [11], Aric and others have done a lot of work on it, and I'm glad to participating too. I think the main blocker for Wine CJK font support is Font Association now, is it suitable for a GSoC project? Also I've filed some other Wine font bugs [12],[13],[14],[15],[16], I'm happy to working on them.
- Improve Wine font test case
This idea is similar with the above one, however, instead of fixing real bugs, this idea is to prevent new bugs(regression). As having filed 100+ bugs I know the pain of doing regression test if we can't script the test, this happens on font related bugs.
The main idea is to integrate an OCR engine to wine testcase, use ORC method to detect whether the fonts display correctly. We already have very good open source ORC engine [17] which is in Apache License. However tesseract-ocr is written in C++ an I am worring that will not be integrated to Wine code tree.
- Improve Wine App install / App running testing
This idea is similar with Austin's early work [18], my idea is using sikuli [19] instead of autohotkey, since sikuli is more powerful for complex work. Sikuli using tesseract as orc engine, so if we done this job we can prevent many font relate regression as well.
- I'm also open to other ideas...
I'm sorry for my long post, and thank you for your time to read it. In fact I have much more things on my todo list regarding to Wine, but time is limit and I have to give up most of them in the near future.
I'm happy to know whether there is anyone working on these ideas, also I'm happy if any others take them as GSoC project :) Rather than to be accepted by GSoC, I'm more glad to see Wine is improved, especially on parts I've mentioned above, that is why I post this long mail. Wish we can see them in Wine 1.6. Of cause, GSoC is awesome to me :)
Any suggestion is appreciated, and feel free to ping me on IRC (fracting).
Last but not least, thanks wine community for such a great project.
Reference: [1] Bug 29460 - Ruijie Supplicant Su1xDriver.sys crashes in driver entry due to ntoskrnl.exe IoGetCurrentProcess() being a stub [2] Bug 27060 - installation of iNodeSetup3.60-6208.exe needs netcfgx.dll [3] Bug 27061 - iNode Client exit silently on start up [4] Bug 30041 - npptools.dll is needed by ishare_user.exe of Dr.com [5] Bug 30208 - NKSetup (Shan Xun 802.1x client) infinite loop while installing [6] Bug 21571 - WinPcap 4.0.1: Setup cannot install Microsoft Network Monitor Driver (NetMon) [7] http://www.winehq.org/pipermail/wine-patches/2011-March/099838.html [8] http://code.google.com/p/online-banking-with-wine/wiki/buglist [9] https://groups.google.com/forum/?fromgroups#!forum/non-ie-online-banking [10] http://wiki.winehq.org/USB [11] Bug 16325 - incorrect font rendering for CJK programs [12] Bug 29851 - Some part of PDFCreator installer cannot display Chinese correctly even Font Replacement is setting correctly [13] Bug 29853 - QQ2011 does not display Chinese correctly with builtin usp10 if font link setting is incomplete [14] Bug 29850 - Scilab does not display Chinese [15] Bug 27285 - Miro does not display Chinese [16] Bug 30263 - builtin iexplore does not display Chinese [17] http://code.google.com/p/tesseract-ocr/ [18] http://wiki.winehq.org/Appinstall [19] http://sikuli.org/
-- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/
Qian,
- Improve Wine App install / App running testing
This idea is similar with Austin's early work [18], my idea is using sikuli [19] instead of autohotkey, since sikuli is more powerful for complex work. Sikuli using tesseract as orc engine, so if we done this job we can prevent many font relate regression as well.
I already asked Austin about that for my GSoC proposal:
in short, I think this effort is best spent somewhere else. GUI testing is really hard to get right, and very expensive(time, effort, disk space, cpu power, etc.).
I've since decided against GSoC for this year, but my idea revolved around improving cmd's parser, notably getting Firefox/Chromium and/or other software to build under wine (or at least, isolate potential/existing issues to non-cmd parts). I was partway through fixing http://bugs.winehq.org/show_bug.cgi?id=21174
Dan Kegel seemed pretty interested in the project. If you're interested you could e-mail him.
Alex
Hi Holy,
On Tue, Mar 27, 2012 at 12:38 PM, HolyCause holy.cause@gmail.com wrote:
I already asked Austin about that for my GSoC proposal:
in short, I think this effort is best spent somewhere else. GUI testing is really hard to get right, and very expensive(time, effort, disk space, cpu power, etc.).
Thanks for reminder, I agree GUI testing is expensive, but I think manpower is more expensive :) However I've no idea how hard is it to get GUI testing right yet, maybe you are right, but from my view it is worth to try.
I've since decided against GSoC for this year, but my idea revolved around improving cmd's parser, notably getting Firefox/Chromium and/or other software to build under wine (or at least, isolate potential/existing issues to non-cmd parts). I was partway through fixing http://bugs.winehq.org/show_bug.cgi?id=21174
Dan Kegel seemed pretty interested in the project. If you're interested you could e-mail him.
Thanks, if this idea is not suitable for GSoC, I'll push it in my todo list. I'll contact to Dan and Austin once I'm going to do this.
Thank you for your suggestion and good luck to your GSoC project!
Hi,
On 3/26/12 10:29 PM, Qian Hong wrote:
- Improve Wine CJK font support
The main idea is fix Bug 16325 [11], Aric and others have done a lot of work on it, and I'm glad to participating too. I think the main blocker for Wine CJK font support is Font Association now, is it suitable for a GSoC project? Also I've filed some other Wine font bugs [12],[13],[14],[15],[16], I'm happy to working on them.
Oh, I would love this. However speaking from experience font code is very hard. You would need to directly specify what you wanted to try to do and what needs improvement. The code there is very messy and fragile but also critical so it gets tricky to make any sweeping modifications.
- Improve Wine font test case
This idea is similar with the above one, however, instead of fixing real bugs, this idea is to prevent new bugs(regression). As having filed 100+ bugs I know the pain of doing regression test if we can't script the test, this happens on font related bugs.
The main idea is to integrate an OCR engine to wine testcase, use ORC method to detect whether the fonts display correctly. We already have very good open source ORC engine [17] which is in Apache License. However tesseract-ocr is written in C++ an I am worring that will not be integrated to Wine code tree.
I dont know if we need OCR. With the dib engine if we have a known font we can probably just do bitmap compares. I am not an expert here but it sounds interesting.
-aric
Hi Aric,
Thanks for reply.
On Tue, Mar 27, 2012 at 7:56 PM, Aric Stewart aric@codeweavers.com wrote:
Hi,
Oh, I would love this. However speaking from experience font code is very hard. You would need to directly specify what you wanted to try to do and what needs improvement. The code there is very messy and fragile but also critical so it gets tricky to make any sweeping modifications.
My favorite is to implement Font Association support, since currently we have no workaround for it without recompile source code. However, before investigate on font issue deeply, could I ask here for other wine developers' work plan? Just half day after I post my previous email, Huw and Kusanagi have sent their patches regarding font support to wine-patch. we have multiple developers working on this area, to prevent duplicate work, could you tell me is anyone working on Font Association support?
Thanks a lot!
I dont know if we need OCR. With the dib engine if we have a known font we can probably just do bitmap compares. I am not an expert here but it sounds interesting.
I didn't known we can just do bitmap compares, if that's possible I think the OCR plan could be schedule low priority, maybe I'll investigate it in the future. Is it a good GSoC idea to improve font related testcase base on bitmap compares?
Thank you!
-
Aric Stewart -
HolyCause -
Qian Hong