GSoC project ideas

[Kai Blin]

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

[Reece Dunn]

On 25/02/2008, Kai Blin  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

[Kai Blin]

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]

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

[Jacek Caban]

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

[Steven Edwards]

On Thu, Feb 28, 2008 at 7:28 PM, Jacek Caban  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.

[Pau Garcia i Quiles]

Quoting Kai Blin :
> 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.

[EA Durbin]

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

[Eric Pouech]

> - 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+

[Scott Ritchie]

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

[Kai Blin]

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]

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]

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

[Jacek Caban]

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

[Steven Edwards]

On Thu, Feb 28, 2008 at 7:29 PM, Jacek Caban  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.