World Wine News

WineBot (http://winebot.sandbox.cz ) is a sort of lightweight implementation of some core thoughts, but with ca ommand line based interface and less dependencies. Both projects share some core ideas and data file formats. The WineBot goals are much smaller in scope than the Wine-Doors ones, going in smaller steps.

The main goal is to replace obsolete and almost unmaintainable winetools project.

Main idea is to make repositories of supported application packages, both installed from CD, HDD or downloaded from net.

For example to install Oblivion by placing CD into tray and entering

winebot install tes_oblivion-1.1.511uk winebot install tes_oblivion-1.1.511uk

Or in case of Wine-Doors - insert CD, run wine-doors, select Games repository, click to add Oblivion to install queue.

Given list of manual steps required to install Oblivion

http://www.uesp.net/wiki/Oblivion:Linux

The problem that Wine developers have with recipes like the one you cite is that most of the steps in the recipe are there to work around bugs in Wine. We would prefer to fix the bugs. For instance, the steps related to sound and winecfg should just go away, hopefully this summer. Likewise with directx and registry settings.

That said, I'm certainly in favor of helping users, as long as it's done 'right', for some hard to pin down definition of 'right'.

I'm going to discuss my personal point of view, as I'm representing Winebot project.

I'll first summarize some points extracted from the previous discussion:

• My goal in writing Winebot is to help Wine succeed
• I pledge to use only the bare minimum of native DLLs in any Winebot recipe
• I pledge to remove native DLLs from Winebot recipes as soon as Wine fixes the bugs that keep Wine's DLLs from being sufficient for that app
• I will report bugs to the Wine project in the course of working on Winebot
• Installation of "basic compatibility programs" sounds like it would clash with "only use the bare minimum of native DLLs / hacks in any Winebot recipe". Winebot shouldn't install anything that the application does not need.
• I will help Wine by writing not just Winebot recipes, but also basic application regression test scripts
• If developers working on projects such as Wine-Doors contributed to Wine, then the bugs would be fixed even faster.
• If you are making it extremely easy for users to run with native dlls and hacky workarounds, then you are hurting Wine. Wine is still beta, and we need as much testing and bug reporting as possible. In short, you leech off the hard work of all the Wine developers and give nothing back in return (quite the opposite in fact).

Each Winebot package shall have a maintainer responsible for package quality and for interfacing with the WINE project (AppDb, Bugzilla, Testing, Fixing).

Every official Winebot maintainer will be bound by a sort of Winebot manifest stating the Winebot project's attitude towards the WINE project.

I'll write the manifest (a),(c) and post it onto Winebot Wiki. To create (b) I gladly accept any input to create a regression test repository, would You be so kind and point me to some list of programs / test miniprograms to make a reference implementation?

• My goal _is_ to help Wine succeed. Hours I'm investing in Winebot are hours I'm spending on learning Wine. Recent discussion about missing reg.exe implementation originated from work on Winebot. I'm application maintainer on AppDb. I'm testing application compatibility on WINE versions back to 0.9.9. I've written Winebot especially to make the testing easier. I often install and uninstall Windows programs from WINE bottles, I'm used to bottles (WINEPREFIX) system, too. Having the installation of programs (and their dependencies) scripted is the first step for making automated testing.
• All Winebot packages should install only the minimum necessary dependencies and their install scripts should be ideally only using normal application Windows installer. Any hacks above will be reported (in case they weren't reported already) to the WINE bugzilla.
• That's a relic from winetools project. 'bottle initialization' will be removed soon as unnecessary. Working package dependencies allow to reconstruct every step of setup and every 'hack' in used packages.
• Yes, I'm planning to set up a regression tests repository for WINE (and for Winebot too). As Winebot is using AutoHotKey system for installer automation, it can also run programs, check window properties and contents, click on specified button or areas, etc. For more information, see http://www.autohotkey.com
• Actually I consider my Winebot work is a work for WINE project and WINE users. If I find some error in WINE, I report. Same when I need new functionality. If I'm capable, I'm trying to discuss, implement and send a patch for WINE. Actually Winebot could help more WINE developers with testing, with testing environment setup and with duplicating bug cases, IMHO.
• User simply wants his application to work. Package maintainer, who prepares the package, should interface with WINE developers whenever he spots a glitch. Package maintainer goes with new WINE versions and prepares a package for each WINE version. Package maintainer is therefore dedicated regular WINE tester and bug reporter. Package maintainer also filters user feedback to create a useful bug report, probably with a patch proposal in ideal situation.

Looks like there's been a regression lately. I'm getting errors like this

X Error of failed request: BadPixmap (invalid Pixmap parameter)
Major opcode of failed request: 54 (X_FreePixmap)
Resource id in failed request: 0x2a0006a

http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/1f41dbd21a129f5e

The error doesn't happen often enough to make a regression test easy, and I haven't tried myself yet.

Could you see if this helps? It looks like XRenderFreePicture actually destroys the underlying pixmap, so we ended up freeing it twice.

I was able to reproduce the badpixmap bug on peachtree 2006 right after picking a company from the "open company" dialog. This patch seemed to fix this (or at least hide it from being as reproducible as it was). I had some trouble applying it to current gitwine, but I typed it in manually and it worked fine.

Where can I get the 0.9.34 wine built for ubuntu feisty?

If you enable the backports repository, you should also get a fairly recent Wine package (roughly what's in the latest development universe). I might want to take over that personally soon.

Sorry that I am a bit behind with the Fedora Extras Packages but there are some bugs I want to clean up before upgrading. Should happen in the next days so.

It is in their Extras RPMs.

Additionally in my buildservice repositories:

http://software.opensuse.org/download/Emulators:/Wine/

It looks like programs/taskmgr/taskmgr used to let you edit debug channels for any process, but now that function seems broken; when I right-click on a process and select 'edit debug channels', I get column headers Debug Channel Fixme Err Warn Trace but nothing under them. Is this supposed to work?

In the meantime, I'll make do with

https://wiki.winehq.org/Debug_trace_toggle_key

I enhanced that a bit and have a patch based on a recent winehq git:

http://repo.or.cz/w/wine/hacks.git?a=commit;h=a3840322693b5630bf8ffd7f85e9287a1e213bd6

I've just sent a fix for this one. Note, that you can only toggle on/off debug channels that are specified on the command line when you start the program (currently you cannot add new debug channels on the fly, even if it would be doable)

Well it is more of a request for adoption than an RFC.....

If someone else wants to pick this up feel free. I am kind of blocked on time. Over the course of the past year the discussion about need for an audio test has come up from time to time. Using a WAV file with PlaySound is too massive due to using embedded resources so next we looked at using an embedded mp3 and the wineacm codec. This would be interesting because then we could have something like the sound of a wine bottle being popped or wine being poured but Alexandre said he would rather have a simple test so I elected to rip Francois winmm audio test as a base.

As for where to take it from here I am kind of at a loss. The more I think about it there could be even better ways to test audio by using DirectSound to generate a set of tones if that's even possible. It would be cool if it was, because then we could do a series of tests like a short tone testing WinMM then another short tone testing DirectSound. This might help users that have choppy sound or missing sound in games but not in other apps. Also how to handle the case where it does not work is rather interesting as right now my little messagebox does nothing, but if we implement the help system Jacek suggested we could provide information on how to debug sound problems linked from the dialog. Last but not least this sound is kind of boring so someone else that understands this code better can add some sort of modulation to the tone to make it more appealing. If I was writing in Qbasic I could have pulled it off but as it stands this is the best you're going to get from me. I learned a good bit over the 8 or 10 hours it took me to strip it down so it's not a total loss even if it's rejected.

If no one else wants to work on this and Alexandre does not hate it then I will submit it to wine-patches on Monday sans DEBUGGING enabled in a proper git diff.

I almost have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files.

My wife hurt a finger trying to impersonate a Samsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing.

ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work.

If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing

#!/bin/sh
pwd > /tmp/log

I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file:

#!/bin/sh
DIR=`dirname "$1"`
DIR=`cd "$DIR"; pwd`
cd "$DIR"
wine "$@"


That worked better; it let ViewSel.exe launch the DICOM viewer.

So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked.

Which version of nautilus (err.. Gnome) were you using? The one in Edgy or Feisty?

I ask, because Edgy seems to not want to run executables at all from double clicking, producing this horrendous error:

http://tuzakey.com/~scott/wine_without_mime.png

I've been told the above is a bug in nautilus. At any rate, it partially resulted from removing the MIME contents of Wine from the packages; this was done for security purposes, and because binfmt-support is supposed to launch the app with Wine. You'll notice in the above image that it does indeed identify the application correctly - nautilus just fails to launch it.

That said, I maintain the Ubuntu packages, and if you've got a fix I can use, I'll certainly incorporate it.