This page is a collection of Wine related projects that come with
a big Cool! factor. I will be tracking their status
on this page, as they are also quite important from a practical
point of view. If you feel like working on any of these, please
let me know.
Desktop Integration
Some of these range from fairly easy to somewhat difficult. The payoff
on these is high - how users interact with the desktop are some of the most
visible parts of Wine. Mike Hearn, who suggested most of these ideas,
explained, these "provide a good intro to Wine development for anybody
who has been lurking on the sidelines and wants to get involved. As usual no
guarantees these patches would be accepted, that's Alexandre's call.
But they probably would be, and you'll learn something while doing them!"
Create My Documents
Map CSIDL_PERSONAL (My Documents) to the $HOME directory if mapped.
See the _SHGetDefaultValue function in dlls/shell32/shellpath.c for an
explanation of how to do this. It would probably be ok to grab $HOME
using the UNIX getenv() and then using the libwine APIs to map them to a
Win32 path. If the mapping fails (i.e. $HOME is not accessible given the
users dosdevices) then just fail with a WARN().
This is similar to above but with some extra work. Map the contents of
the ~/Desktop directory to the Windows virtual Desktop folder. In file
pickers and Explorer, the filesystem root is represented by a magic Desktop
folder. In real Windows this reflects the icons that are on the desktop and
is mapped to a real directory at some arbitrary point in the filing system.
On Linux we have no such virtual root, however it'd be nice if icons that
appeared in the KDE/GNOME desktop were put in their proper place. That way
users won't be confused by the file being on their desktop but unavailable
from their Windows applications file picker.
This should not be too hard. The Desktop folder is implemented by a COM
object in dlls/shell32/shfldr_desktop.c. You just need to read the
$HOME/Desktop folder and put the items you find in there inside. Ignore
.desktop files for now, they are a bit tricker to map and aren't especially
useful for us anyway.
You also want to map CSIDL_DESKTOP in dlls/shell32/shellpath.c,
_SHGetDefaultValue. See above.
Bonus points for fixing the desktop icon while you're at it (an arrow??!)
The freedesktop.org icon theme specification shows us how to find icons
for many different types of things. Implement support for loading and
using the following icons from the icon theme (it should be OK to use
native libraries for this like GdkPixbuf, just fall back to the compiled
in defaults if it's missing):
folder
desktop
computer
unknown document
any others??
Don't do file types, as native icon<->file type association is done by
mime types not extensions, and it'd make our file dialogs even slower than
they already are.
You may be tempted to use e.g., libpng to implement this. Don't! Use
GdkPixbuf instead, stock icons are allowed to be in many formats including
SVG.
Actually it's probably easier to use the new GTK+ APIs to implement this,
that takes care of not only rendering the image to a raw bitmap you can
then convert to an HICON, but it also implements the icon lookup algorithm
for you. In future it'll probably also implement some fancy caching
mechanism to reduce memory overhead. Might as well get these benefits
easily!
workers: wanted
status: to do
updated: Dec 21, 2004
XDG Menu Support
Try updating the menu mapping code to support the new XDG menu
specification. Don't bother trying to make this work everywhere, it's a
total nightmare. Just try supporting the new standards. Be warned: not
every desktop/distro supports this yet!
This one might be quite hard.
workers: wanted
status: to do
updated: Dec 21, 2004
Improve winebrowser Script
Try improving the winebrowser script to take into account the user's
preferred applications. At the moment it just tries every browser it
knows about in a hard coded order. Hint: in modern GNOME desktops you can
use the "gnome-open" program to make this automatic. There is a KDE
equivalent (kfmclient openUrl).
workers: wanted
status: to do
updated: Dec 21, 2004
Integrate Windows Screensavers
Integrate Wine with XScreensaver, so installing Win32 screensavers makes
them automatically appear in the list. You may need to write patches for
xscreensaver to make this really slick.
Bonus points for getting xscreensaver to respect the registry
setting LowPowerActive.
workers: wanted
status: to do
updated: Dec 21, 2004
Take Out the Trash
Steven Edwards suggested, "add support to use the draft FreeDesktop
trashcan spec."
workers: wanted
status: to do
updated: Dec 21, 2004
Integrate the Registry With Native Configurations
Implement a bridge between the Windows registry and the GNOME/KDE
configuration systems. If you set the wallpaper in a Windows app
it should reflect on your real desktop. This is useful for programs
like the WebShots desktop. This could be done by extending the
wineexplorer
workers: wanted
status: to do
updated: Dec 21, 2004
Configure Some Default Registry Entries
Stefan Dösinger suggested, "probably a bigger task: Look for common
native applications and write entries for them into the registry. For
example, I manually added an entry for KMail in \\Machine\\software\\clients
and now I can select Kmail as the default Mail application in the internet
options control panel (Which is created when Internet Explorer is installed).
My registry entries look like this:
I selected KMail as the default Mail application, and when I open an Mail
Address in MSIE kmail pops up. The same happens when I enter a mailto:
address in Task Manager->New task.
workers: wanted
status: to do
updated: Dec 21, 2004
Virtualization Projects
Virtualization environments tend to stress the host considerably,
due to the inherent impedance mismatch between the two. As such,
they provide very good (and tough) test cases. Having such
virtualization environments run within each other is an important
milestone in the lives of said projects, and not without good
reason: it is a remarkable technical feat that requires a great
deal of maturity.
Platforms
Wine provides Windows in Linux;
Cygwin provides Linux in Windows.
Why not run one inside the other?
NB: having them both work would allow us to nest them arbitrarily,
which would be ubercool.
Cygwin under Wine in Linux
This provides an a good test case for Wine. It is tough, but we do have
the Cygwin source code, and we have a good chance to understand why it
does not work.
This task is tracked as Bug #443
This will provide a good test case for Cygwin, but will help Wine's
portability. Moreover, the ability to run Wine code under Windows
without a reboot, can help with testing sometimes.
This task is tracked as Bug #273
Over the past 10 years, a number of portable runtimes have been created.
Why not use them in a way they weren't meant to be used? That is, compile
and run their Windows port on Linux under Wine. For this to happen, they
need to have a MinGW port on Windows (that is, they need to support
building under MinGW).
Update: The ActivePerl branch support building under both Cygwin and MinGW.
This is a very good test for winegcc. Unfortunately, the MinGW makefile uses
backslashes as fileseparator, so it will take a bit of work to get working under Linux.
Why do people use backslash, when the forward slash works on both Windows and Linux?
Python
Not very exciting, but still interesting port. It's a good test for the
non graphic APIs, such as threading, files, etc.
Unfortunately, configure gets confused about the executable extension,
and needs to be hacked manually to suppress it. It still determines
that an .exe extension is needed, so the definition of the EXE variable
in the resulting Makefile must be manually adjusted. Things compile
fine, but linking unfortunately fails. winegcc needs more work
to support the -Xlinker, and -shared options.
Update: Here is an
article
containing a log of successful compilation of Python 2.2 using MinGW.
Toolkits
While some have focused on portable runtimes (see above), others tried
to create portable UI toolkits. Due to the large UI component of the
Win32 API, these are a perfect test for Wine.
QT
Imagine we compile QT under Wine, and then we get the entire KDE
compiled and running under Wine! How cool would that be?
Update: It seems that both Qt3 and Qt4 can be compiled with MinGW.
This should make a Winelib port feasible.
Gtk+
This is maybe a little less interesting than the others, as Gtk+ does not use
the native widgets when ported to Windows. Instead, it uses it's very thin
abstraction layer (gdk) to do the drawing, all else is build 'in house'.
The first try at porting wxWindows to Wine was attempted by
Robert Roebling.
His work was later on improved by Julian Smart.
Unfortunately, it never seemed to have reached a fully functional stage, and
seems to have started bitrotting as a result. Due to numerous bugs in Wine
at the time, they were forced to add multiple ugly hacks to the wxWindows code.
My current porting effort is a brand new approach, that builds on the MinGW port of wxWindows.
In theory, wxWindows should work with just a few lines changed in the makefile. Practice is however
a bit different, and a bit more work is required. That being said, I will try to minimize to the
absolute minimum the changes required to wxWindows (unless such changes would correct problems).
Rather than working around Wine bugs, I am fixing them as I go along, and submit them for integration
in the Wine tree.
This one compiled with just a couple of trivial fixes to Wine's headers, a few portability
fixes to their source, and just one or two Wine specific tweaks.
Source portability
We should be able to compile Wine with various C compilers.
Microsoft's Visual C
The most popular compiler in the Windows Universe. Also known as Visual C++,
Visual Studio, or MSVC. You can download a free version of the command line
compilers from msdn.microsoft.com/visualc/vctoolkit2003.
The Wine test programs do seem to build with Visual C (see posts by
Jakob
Eriksson and Dan
Kegel). Wine itself, does not build under MSVC currently.
status: most tests work, DLLs are pretty bad though
updated: Nov 29, 2002
Borland's bcc
Borland has released it's C++ Compiler 5.5 as freeware. The compiler is the core of
C++Builder, and is capable of creating fully functional C++ applications from the command line.
Sybase acquired the compiler from Watcom, and released it as Open Source software.
Currently it is being ported to FreeBSD and Linux, and a Windows version is readily
available.
status: older version that didn't support stdcall. I abandoned that project years ago...
updated: Dec 1, 2002
Others
Make a ghostscript driver that uses Wine to print
When we are going to support native Windows printer
drivers, this is going to allow ghostscript to use
any of the existing gazillion printer drivers out there.
This is still a virtualization project, but at the printing
subsystem level. The complementary project (use ghostscript
to print from Wine) has been implemented, and working just fine.
A Wine based GIMP plugin for using Photoshop plugins
Suggested by Marcus Meissner:
Investigate if we could make a WINE based GIMP plugin which can handle
Photoshop plugins.
wined3d use wgl
Make wined3d (or d3d8) use wgl (windows opengl) instead of glx. (just search for glx commands and
replace then with the wgl equivalents) Doing so would enable wine's d3d to run on windows in place of
the windows driver and without the rest of WINE which would greatly help in debugging. It would also
allow wined3d to use the wgl implementation in wine.
workers: Aric Cyr
status: debug phase
updated: Jan 12, 2006
Miscellaneous Projects
This is a catch-all category for all sort of strange (and sometimes cute) ideas.
Cross referencing the Windows executables and libraries
The idea is to write a Perl script that analyzes the Windows dlls and executables of a
regular Windows installation and cross references them. This would generate Web pages
telling you which API is used by which program/library and reciprocally.
Analyzing the import/export section of PE executables is quite simple: it's just a matter
of running dumpbin (part of Visual C++) or pedump (open source) on them and then parsing
the resulting text file. This already being done with the wpbtk toolkit.
Update:
Currently the script can make HTML maps of the dll imports. I've been too
lazy to integrate the program that processed that into a table so
far. :) Right now it requires dumpbin (Visual C++) I plan to add pedump
or winedump support so more people are able to use it. It is also
analyzing the Wine .spec files to determine if each API has an entry and
reports whether it's a stub, unimplemented (not in spec files), etc.
Check which APIs are missing for a given program
The scripts that scan a Windows environment could be modified to restrict the scan to the dependencies
of a given executable/set of executables. Then these results can be cross-referenced with the results
of the above script to tell you which APIs this program is missing, what percentage they represent, etc.
Reciprocally one can weight each API according to how often they are referenced in a given environment to
produce an approximation of the likely hood that such an API will actually be called. Note that this would
just be an approximation because we would miss all the dynamically loaded APIs and libraries
(since we only scan the statically linked dynamic libraries). This would be an even more approximate
measure of the likely hood that the program will work: even though a program references an API it may never call it,
work even though this API does not work, or really depend on this API or even some undocumented aspect of this API.
Still this may provide a better approximation of the completeness of Wine than just treating all APIs as equivalent.
Microsoft GDIplus currently works on Wine already, however it might be faster if we can take advantage of the
Mono project's libgdiplus implementation as
it can use the Cairo vector graphics library or OpenGL as a backend. There are 4 efforts underway at this time
to make a free gdiplus.dll replacement for Windows and one example is The Gimp for Win32. However they are still
going to suffer from the same problem of being implemented on top of the GDI. And if we can use the Mono
libgdiplus we just might end up with apps that render faster than on Windows.
The standard Windows console has Copy & Paste toolbar icons.
Adding them to wineconsole would be a very nice project for
someone who knows a bit about windows programming. This task is
tracked also in Bugzilla, as
Bug #1304.
Wine Explorer
A Windows Explorer replacement. People migrating from Windows would love it,
and it would provide a great testbed for our shell32 DLL, as well as
some key controls such as the List-View Common Control.
Would be nice to have a shell exe (sort of like the one provided by JUnit),
that contains the little exes, extracts them in a temp dir one by one,
runs them, and displays a nice progress bar, together with a list with messages.
Many applications are compressed with EXE packers or use other tricks to
thwart those who would try to look inside them. These applications typically
crash or refuse to run if they think a debugger is being used. The tests
used generally involve taking advantage of some undocumented quirks in the API.
It turns out that many of these tests fail with Wine. This is often because
Wine does not implement a feature the exact way the application expects. There
is some sample code available
here and
additional information here.
Getting this kind of code to run and give the correct results could help with
other stubborn applications that depend on the same feaures.
workers: wanted
status: to do
updated: Oct 22, 2003
JScript engine
Implement jscript.dll. Use Mozilla's
SpiderMonkey
to implement the
Windows scripting interfaces
for the JScript COM object in
jscript.dll.
Figure out a way to deal with the differences between JScript and JavaScript.
