WHAT'S NEW with Wine-20041201: (see ChangeLog for details)

• Implementation of the RSAENH dll.
• More work on the Direct3D 9 architecture.
• Builtin debugger improvements.
• Reorganisation of the Developer's Guide.
• Lots of bug fixes.

I'm sitting waiting for a couple of compiles to finish, so I thought I'd put together a list of fun/interesting tasks people might like to have a go at related to better integrating Wine with the native desktop.

None of these should be especially hard, and so would 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! :)

Task 1:

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.

I think it'd 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().

Task 2:

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??!)

Task 3:

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.

[ed note: and later he added...] 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!

Task 4:

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.

Task 5:

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.

Task 6:

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.

wineshelllink supports update-menu which itself builds xdg compliant menus (via /etc/menu-methods/menu-xdg).

I know mandrake and debian distro use "menu", need confirmation for RH/Novell newest releases.

It would be more elegant to let menu manage gnome/kde/xgd/wmaker ... than reimplementing them in wineshelllink . The strongest point is that menu build menu via methods which are tweakable by distro builder. Thus it will avoid to upgrade wineshelllink whenever we want to support gnustep xdg version 12 and the like.

I would like to add support to use the draft FreeDesktop trashcan spec. I am working on this a little with one of the ReactOS guys but it will be a while before we have a patch ready.

Another suggestion, 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:

[Software\\Clients\\Mail\\Kmail] 1100110998
@="KMail"

[Software\\Clients\\Mail\\Kmail\\Protocols\\MailTo] 1100110998
@="URL:MailTo Protocol"
"EditFlags"=hex:02,00,00,00
"URL Protocol"=""

[Software\\Clients\\Mail\\Kmail\\Protocols\\MailTo\\DefaultIcon] 1100110998
@="C:\\Program Files\\Opera\\opera.exe,1"

[Software\\Clients\\Mail\\Kmail\\Protocols\\MailTo\\shell\\open\\command] 1100110998
@="\"Z:\\usr\\kde\\3.3\\bin\\kmail\" \"%1\""

With Z: mapped to /

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.

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.

Actually I already have the code for such a "wineshell" program in a local tree, for the system tray integration. I'll see if I can get it submitted soon. We could put all this integration stuff there once it's integrated into Wine.

I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposes. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started.

There is nothing wrong with fixing a bug for its own sake and any bug we fix will ultimately improve wine and provide some insights into debugging wine.

That being said, I would agree that at least to some degree this should be a training exercise and that whatever bug(s) we go after, some (budding?) developer would like to have fixed. However there should be a bug report in bugzilla so that developers can research the bug in the first place and we can keep track of what was done for these sessions. I have created a key word "BugBuster" in Bugzilla to keep track of candidates. Hopefully after several sessions we will have a list of fixed bugs that new developers can use as a reference.

Just for the record, I'm still trying to develop a "proper" RichEdit control. I've written from scratch with RichEdit compatibility in mind, so I don't expect any copyright or suitability problems. At least, unless I screw something up or I'm less smart than I think.

If someone isn't afraid of running closed-source .exe from barely known developer (or can run it in a controlled environment), you can find the latest binary at:

http://foltman.com/riched.zip

I'm not releasing the source yet, because I don't think it's hackable, until at least its architecture is complete. What's more, I'm planning to license a heavily modified derived product comercially to some company (a rich text viewer/editor tailored for a specific application), so any copyright-related problems are undesirable.

What IS done:

• basic text wrapping with support for proportional fonts and character formatting, no major known bugs (the only supported attribute is Bold, but the rest will be relatively easy to add)
• simple editing (typing text, backspace, delete, no overwrite mode yet)
• a very incomplete implementation of Shift-arrow selection (done in a few hours yesterday :-) ), mouse operations don't support selection yet
• per-paragraph alignment
• pitiful low-level style management
• bold attribute
• some basic optimizations (avoiding rewrapping unmodified paragraphs unless editor window is resized)
• uses UNICODE internally (not necessarily a good thing)

What isn't done:

• RichEdit API (which is a mess; I'm taking care of it in order to ensure compatibility wrt how editing functions work, however, basic editing functionality is the number one priority, as it's more difficult to achieve)
• RTF interface
• Undo
• Clipboard
• tabs
• bulleted lists
• setting paragraph attributes (margins are implemented internally but can't be changed with current interface, setting alignment by Ctrl+L/E/R works)
• all RichEdit f3 functionality
• MBCS support (and it would be very hard to add)
• BiDi and CTL support (ditto)
• everything not mentioned in the first list

I have been working on richedit a little also, and am quite keen to get the ball rolling by having some richedit 2.0 code in winehq so that others can help work on it. I'm quite interested to see the source for this.

Whether you show us or not, the copyright for the source still belongs to you. If you choose to license it under LGPL, then you can still release it under a different license later, so long as you are the sole author.

I think you'll find that the development proceeds much quicker if you release your source, and get it integrated into the Wine tree sooner rather than later. People will submit patches fixing your code, and new features.

When you do release your "completed" riched20 code, LGPL patches will still be submitted against it, and you'll experience the same licensing problems if you wish to incorporate other people's code.

Frankly speaking, people promising to release their source code "at a later date" are an impedement to development, because nobody is motivated to work on the promised feature in the meantime.

Please consider "release early, release often", so we can work together on this :)

I changed the install script a bit and it does not depend on DCOM98, MFC4.0, etc... anymore. So, you can run IE6 completely out-of-the-box.

New script is here :

http://sidenet.ddo.jp/winetips/files/wine-config-sidenet-1.5.3.tgz

Quick tip: if you grab the IEBATCH file from my IE installer script:

http://bylands.dur.ac.uk/~mh/wine-ie

and put it in your script then the IE installer won't prompt the user for any information when installing. This is good as not all the things it would otherwise install work yet. Also it makes it a fully automatic hands-free install which I quite like.

I have released a preliminary version of the Darwine SDK version 0.1. Many people are interested in getting Darwine up and running so they can compile programs on OS X and this release should satisfy their curiosity. The SDK features the following:

• source code for the current Darwine binary 20040820
• source code for WineHelper
• Xcode Integration
• Xcode Template
• Updated Uninstaller

The Xcode integration allows for a user to compile windows source code from within the Xcode IDE using the wine tools. Users may want to note that there are some changes to the way Darwine is installed and functions. Due to limitations in Xcode, the wine source tools such as winegcc, winemaker, winebuild are installed in the /usr/bin directory and not the /Library/Darwine/bin directory. This may be changed in a future release but was necessary so Xcode integration would work correctly. As a result there is an updated uninstaller as well. The uninstaller will remove everything except for the Xcode project template folder, which is moved to the trash and needs to be removed manually.

To start a new Darwine project, simply launch Xcode, select new project, and select Darwine (Windows) Application. Currently in Xcode the "Build and Run" does not work, it will build the program but not launch. However, the Build button works as expected. When compiling a Darwine application for the first time Xcode may give the error:

ld: table of contents for archive: /Library/Darwine/lib/wine/lib<name>.a is out of date; rerun ranlib(1) (can't load from it)

Open a terminal and type the following command:

sudo ranlib /Library/Darwine/lib/wine/lib<name>.a

<name> being replaced by the name of the library whose table of contents is out of date.

The source code should then compile fine. There are many examples of source in the wine source code "programs" folder which is located in the root of the source directory. Simple programs should compile fine. However, bigger programs that depend on more of the windows headers will probably not compile due to header incompatabitlies between the wine and OS X headers.

You can download the preliminary release here http://prdownloads.sourceforge.net/darwine/Darwine_SDK0.1.dmg?download or through the Darwine web site http://darwine.opendarwin.org

Post any comments, questions or concerns to the Darwine Mailing List "darwine-devel_at_lists.sourceforge.net" .

Remember this is a preliminary release and there are many bugs and issues that need to be worked out and features that need to be implemented. More information will be posted on the Darwine website in the near feature.

Last but not least enjoy.