Hi, as promised, I'll start off this thread with the ideas we have on the wiki page [1] right now: * Implementing a WinePluginApi so other programs can use Windows DLLs inside of Linux apps * Improving our HTML/Win32 Help viewers. * Implementing the ASIO audio infrastructure for Cubase * Implement the MS Wsock dll (dlls/mswsock), an enhanced winsocket implementation * Valgrind and Wine integration (see: Wine_and_Valgrind) * Complete the Wine Web browser (aka. Internet Explorer) ie. frame controls, toolbar, status bar * Full URLMoniker implementation. (IE working with builtin urlmon.dll) * Implement transacted mode for OLE32 Storage (STGM_TRANSACTED) * Improve cmd.exe compatibility * Get Mozilla compiling as a Winelib application (http://www.winehq.org/site/winelib#mozilla) * Run the Mauve Java test suite against Sun's Windows JRE, and file bugs / write test cases in C / fix anything it finds * Run the MDAC conformance test suite against Microsoft's MDAC, and file bugs / write test cases in C / fix anything it finds * pick some real-world app or game that doesn't work well, and improve Wine so it installs and runs the app better. (Some good examples might be Photoshop, Visual Basic, a game etc) * pick a Windows feature that is incomplete in Wine, and improve the feature and its conformance tests. (Some good examples might be riched20, DirectPlay, etc) Feel free to add your own project ideas, maybe elaborate a bit on the deliverables of the idea. Cheers, Kai [1] http://wiki.winehq.org/SummerOfCode -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
On 25/02/2008, Kai Blin <kai.blin(a)gmail.com> wrote:
Hi,
as promised, I'll start off this thread with the ideas we have on the wiki page [1] right now:
Some ideas: * Wine 1.0 related projects - this is likely to be fixing bugs, but is there anything in there (or a group of bugs) that is worthy of project status? * Command line API into the installer/uninstaller, winecfg and other tools. This [http://wiki.winehq.org/ConsoleConfiguration] is desired by Ubuntu - and would be useful to other distributions and scripts - for automating a Wine setup. * Other integration/usability improvements. See the [https://wiki.ubuntu.com/BetterIntegratedWineSpec] wiki page for ideas. * Improve the theme implementation to support user32 controls. (Do we also want to support window frames when in desktop/self-rendering mode?) - Reece
On Monday 25 February 2008 09:39:23 Reece Dunn wrote:
* Wine 1.0 related projects - this is likely to be fixing bugs, but is there anything in there (or a group of bugs) that is worthy of project status?
I think it's kind of tricky to judge the scope here. I think the consensus from WineConf was to look if the project was doable first, and if we'd like to have that feature second.
* Command line API into the installer/uninstaller, winecfg and other tools. This [http://wiki.winehq.org/ConsoleConfiguration] is desired by Ubuntu - and would be useful to other distributions and scripts - for automating a Wine setup.
We'd need word from Alexandre if such patches would have any chance at getting accepted.
* Other integration/usability improvements. See the [https://wiki.ubuntu.com/BetterIntegratedWineSpec] wiki page for ideas.
This one seems like lots of work, but I think it's possible to cherry-pick a set of things that are doable. Partly depends on the previous item, though. -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
On Monday 25 February 2008 09:24:10 Kai Blin wrote:
* Implementing a WinePluginApi so other programs can use Windows DLLs inside of Linux apps
Scope seems a bit tricky here, but this is not my area of experience. Comments?
* Improving our HTML/Win32 Help viewers.
What needs to be done here? Did last year's CHM compiler project produce any results? Jacek, you mentored this, comments?
* Implementing the ASIO audio infrastructure for Cubase
Is this already implemented?
* Implement the MS Wsock dll (dlls/mswsock), an enhanced winsocket implementation
There was a project about this in 2006. What happened to that one? Eric Pouech mentored this one.
* Valgrind and Wine integration (see: Wine_and_Valgrind)
Dan, you're the Wine and Valgrind person. How much integration does this still need?
* Complete the Wine Web browser (aka. Internet Explorer) ie. frame controls, toolbar, status bar
Steven Edwards suggested some work on that recently. Is there enough work left to make this a full SoC project?
* Full URLMoniker implementation. (IE working with builtin urlmon.dll)
That one's for Jacek to comment. :)
* Implement transacted mode for OLE32 Storage (STGM_TRANSACTED)
Rob, probably for you.
* Improve cmd.exe compatibility
This is a bit unspecific. Do we have a set of deliverables for this one?
* Get Mozilla compiling as a Winelib application (http://www.winehq.org/site/winelib#mozilla)
Looks like Mozilla builds in mingw32 now, so maybe that webpage should be updated. I'm not sure how much effort this project actually would be. Comments, anyone?
* pick some real-world app or game that doesn't work well, and improve Wine so it installs and runs the app better. (Some good examples might be Photoshop, Visual Basic, a game etc)
Scope-wise, these are really tricky. I'm not sure if we should keep this line on the wiki at all.
* pick a Windows feature that is incomplete in Wine, and improve the feature and its conformance tests. (Some good examples might be riched20, DirectPlay, etc)
RichEd20 has been targeted by two SoC projects so far. How much work is left there? DirectPlay finally seems possible now that the protocol spec was released. I'm happy to mentor something like that. Can we come up with more dlls that might be needed? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
Kai Blin wrote:
On Monday 25 February 2008 09:24:10 Kai Blin wrote:
* Improving our HTML/Win32 Help viewers.
What needs to be done here? Did last year's CHM compiler project produce any results? Jacek, you mentored this, comments?
What I've mentored was something else - it was a chm compiler that would allow us to make use of HTML help in Wine (eg. winecfg help) and winelib apps. HTML help is almost at the same state as it was year ago. I've improved it then to be able to use some simple chm files, but much more is needed. Most functionality is not implemented (just run hh.exe and look...) and API is almost totally not implemented. Also current implementation can't handle many chm files. I think project that would improve things would be good.
* Complete the Wine Web browser (aka. Internet Explorer) ie. frame controls, toolbar, status bar
Steven Edwards suggested some work on that recently. Is there enough work left to make this a full SoC project?
Yes, definitely there is and it would be a great project IMO. It would be even netter if UI was designed to be compatible with IE. It means implementing plug-in support.
* Full URLMoniker implementation. (IE working with builtin urlmon.dll)
That one's for Jacek to comment. :)
urlmon.dll is much improved since then. Although there is still a lot to do, even more than a complete SoC project, someone interested in it would have to find other goal than working IE IMO.
* Get Mozilla compiling as a Winelib application (http://www.winehq.org/site/winelib#mozilla)
Looks like Mozilla builds in mingw32 now, so maybe that webpage should be updated. I'm not sure how much effort this project actually would be. Comments, anyone?
AFAICT Mozilla support for mingw32 is not really good (I've tried it and decided to go back to MSVC) and it's even worse if you try to compile it from Linux. I would very appreciate if someone would fix that. Even better if it was a Winelib port. From my experience their makefiles are, hmmm, not really nice to work with. Anyway, that would be my favorite SOC project. Thanks, Jacek
On Thu, Feb 28, 2008 at 7:28 PM, Jacek Caban <jacek(a)codeweavers.com> wrote:
AFAICT Mozilla support for mingw32 is not really good (I've tried it and decided to go back to MSVC) and it's even worse if you try to compile it from Linux. I would very appreciate if someone would fix that. Even better if it was a Winelib port. From my experience their makefiles are, hmmm, not really nice to work with. Anyway, that would be my favorite SOC project.
If we want to make this a SoC project, I can help mentor it a bit unless someone else wants to step up. I was thinking about giving this another shot myself using Han's mingw rpms he supports for CrossTesting. I've got quite a bit of experience on the mingw side from my ReactOS days and have followed the Mozilla/Firefox mingw progress since the start of time so I think I could help a student get started. I don't have much spare time to actually work on it so having a student do with with some monetary motivation would be a good thing. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Quoting Kai Blin <kai.blin(a)gmail.com>:
Hi,
as promised, I'll start off this thread with the ideas we have on the wiki page [1] right now:
* Implementing a WinePluginApi so other programs can use Windows DLLs inside of Linux apps
In case this is taken by someone, KDE 2.0 had a KPart component called reaKtivate which provided exactly this. It's still in SVN: http://websvn.kde.org/tags/unmaintained/3/reaktivate/ svn://anonsvn.kde.org/home/kde/tags/unmaintained/3/reaktivate It depends on KDE 2.0 and Qt 2.2. I started to port it to KDE 4.0 / Qt 4.3 but I had to put it on hold due to lack of time. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
I've got a huge pile of MSDOS applications that don't work in wine yet. Winedos needs some work. I would like to rewrite ICMP.dll to wrap around the ping command for an SOC project and fix bug 8332 or work on winedos. _________________________________________________________________ Helping your favorite cause is as easy as instant messaging. You IM, we give. http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
* Implementing the ASIO audio infrastructure for Cubase
IIRC, we dropped it last year because of copyright in Steinberg license. Haven't heard it has changed.
* Implement the MS Wsock dll (dlls/mswsock), an enhanced winsocket implementation
still lots to do, basic tests and very low fruits have been done in GSoC two years ago. there were some showstoppers linked to wine internals (mainly in server) which have been fixed. should be ripe for a second turn, however, the project won't be simple
* Valgrind and Wine integration (see: Wine_and_Valgrind)
the only interesting point would be to support MS debug info in valgrind, but I see it more as valgrind's gsoc rather than a wine's one other idea: - window less support in richedit: a couple of bugs are pending on this one (and incendally, lots of COM related code in richedit) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)
Kai Blin wrote:
Feel free to add your own project ideas, maybe elaborate a bit on the deliverables of the idea.
Here's my idea that I'm hoping someone will take up: Write a case insensitive FUSE filesystem for us to put the entire ~/.wine directory in. See http://wiki.winehq.org/CaseInsensitiveFilenames There are two main advantages to this: Sometimes applications break because users need to install a patch by hand into the filesystem (say, a zip file), and the files within have a different case then the files they're supposed to overwrite. This leads to multiples of the same file, and Wine sometimes chooses the older one, leading to weird breakages. More importantly, a FUSE filesystem like this would allow us to finally get some speedups by no longer having to prove case-insensitive files don't exist. This is a direct cause of some apps working very very slowly, including install shield (see http://bugs.winehq.org/show_bug.cgi?id=3817) Interestingly, this doesn't strictly have to be a Wine SOC project. It could fairly easily stand on its own. We'd probably be the only user though, so I mention it here. Thanks, Scott Ritchie
On Monday 25 February 2008 22:54:57 Scott Ritchie wrote:
Write a case insensitive FUSE filesystem for us to put the entire ~/.wine directory in. See http://wiki.winehq.org/CaseInsensitiveFilenames
There are two main advantages to this: Sometimes applications break because users need to install a patch by hand into the filesystem (say, a zip file), and the files within have a different case then the files they're supposed to overwrite. This leads to multiples of the same file, and Wine sometimes chooses the older one, leading to weird breakages.
More importantly, a FUSE filesystem like this would allow us to finally get some speedups by no longer having to prove case-insensitive files don't exist. This is a direct cause of some apps working very very slowly, including install shield (see http://bugs.winehq.org/show_bug.cgi?id=3817)
Interestingly, this doesn't strictly have to be a Wine SOC project. It could fairly easily stand on its own. We'd probably be the only user though, so I mention it here.
Sounds like an interesting project. I see you've already added it to the wiki page. I think the effort is in scope for SoC, though I haven't really played with this yet. Thanks, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
On Monday 25 February 2008 09:24:10 Kai Blin wrote:
Feel free to add your own project ideas, maybe elaborate a bit on the deliverables of the idea.
Marcus Meissner added * DirectInput : Implemented DirectInput8 specific features: ActionMapping and Enumeration by Semantics to the wiki page. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
On Monday 25 February 2008 09:24:10 Kai Blin wrote:
Feel free to add your own project ideas, maybe elaborate a bit on the deliverables of the idea.
How about a project to implement a real interface for Wine's built-in iexplore.exe? Ideally, this would not only give a menu and toolbar but also be compatible with third-party addons. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.
Kai Blin wrote:
On Monday 25 February 2008 09:24:10 Kai Blin wrote:
Feel free to add your own project ideas, maybe elaborate a bit on the deliverables of the idea.
How about a project to implement a real interface for Wine's built-in iexplore.exe? Ideally, this would not only give a menu and toolbar but also be compatible with third-party addons.
That would be a great SoC project IMO. I'd be even more interested in correct architecture than in implementing whole GUI. By architecture I mean mainly plug-in API (project like "Get Google toolbar working with Wine IE"?). Thanks, Jacek
On Thu, Feb 28, 2008 at 7:29 PM, Jacek Caban <jacek(a)codeweavers.com> wrote:
That would be a great SoC project IMO. I'd be even more interested in correct architecture than in implementing whole GUI. By architecture I mean mainly plug-in API (project like "Get Google toolbar working with Wine IE"?).
Whats your estimate on how long it should take to implement enough of the plug-in API to do this? My thinking was to break the Internet Explorer project down in to deliverables with the structure and at least a good chunk of the API being a requirement along with the GUI. Most of the resources/dialogs would be of use one the full plug-in API was implemented I would think. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
participants (8)
-
EA Durbin -
Eric Pouech -
Jacek Caban -
Kai Blin -
Pau Garcia i Quiles -
Reece Dunn -
Scott Ritchie -
Steven Edwards