Thread: So I made a script for Wine...

...a script called winefix. In short, it allows Wine applications to be run just as easily as those native to Linux, meaning that they can be linked to or run from any directory, whether from a terminal or even a file manager like nautilus. It also handles some of the more awkward Wine extensions like .lnk and .msi, akkowing them to be run with a double click.

It also offers a good number of enhancements and fixes over "vanilla" Wine, especially in regards to Compiz and Beryl. If either of the two are running when a Wine application requiring DirectX or OpenGL is run, you'll be asked if they should be temporarily disabled, and reinstated immediately after the application exits. it also allows for the "Legacy Apps" workaround in Compiz Fusion to be similarly enabled and disabled, as always leaving it on is a disaster - while it can fix the fullscreen modes of Wine apps, it actually breaks those of most native ones. The other enhancements allow the option for each application to have it's own dedicated virtual Windows desktop (basically whether a program should be started "windowed" ), be reniced, ensure that fullscreen applications restore the desktop resolution properly, or, for 64 bit machines, run in 32-bit compatability mode (thanks to mikey for suggesting the last two!)

The script also changes Wine's error reporting behavior. Wine normally reports every error and fixme message that is encountered when an application is running, meaning that running programs via terminal results in a deluge of error messages that can greatly hurt performance, and that running them via script or file manager results in losing the ability to see any error messages at all. This script, by default, only reports critical system and Wine error messages, and only displays them if a Wine program actually crashes, in which case you'll then see a dialog much like this:

If it's the first time a particular application has crashed, you'll also be given the option to view its Winehq.org Application Database page, or if not found, asked if you'd like to create one.

The script also allows for more thorough error reporting by the use of command line options. Adding the flag "-d 1" causes all errors normally reported by Wine to be displayed, and saves application to the "log" folder in your Wine directory. There's also a "-d 2" option that causes ALL errors and system relays to be reported, but it's really only useful for debugging (it's insanely slow).

Using the script is pretty easy - it's used in exactly the same manner as wine itself, ie 'winefix drive_c/Program Files/dwarfort.exe' or 'winefix "C:\Program Files\dwarfort.exe"', and accepts all of wine's environment varables. It adds many command line options as well - run "winefix -?" in a terminal for a complete list.

The easiest way to use the script is to install the attached deb - the script will be automatically integrated with Gnome, allowing Wine apps to be run with a double click - something that can't be reliably done with Wine alone (see Bug #1, below). It does the same with Wine files of the .msi, and .lnk extensions, and adds Tango icons to the Wine menu as well:



Don't want a .deb?

If you want the script by itself, grab it from here, save it to your home directory, and install winefix with the command:

Code:

sudo tar -xvvzf winefix.tar.gz -C /usr/bin/

You'll also need to have zenity installed, and optionally lynx for AppDB integration, so if you don't:

Code:

 sudo apt-get install zenity lynx

If there are any bugs, problems, or suggested improvements, please let me know.

If you want to run Wine apps in another xserver, you should take a look at my other script.

##########################
# Bugs and annoyances fixed #
##########################

#1 - Applications breaking when not run from their base directory.
The usual fix is to change to the base directory of an applications before it is run. The script does this automatically, saving you the trouble and allowing the ability to double click Wine executables in a file manager instead of having to run them via terminal or launchscript.

#2 - Wine's finicky handling of links (symlinks) to executables.
If you've ever tried right-clicking on an executable and creating a shortcut to place on your desktop, you know full well this. This script acts as a symlink interpreter of sorts for Wine, allowing symlinks to be used without error.

#3 - Desktop panels overlapping the screen of fullscreen applications when Wine is used with Compiz or Beryl, and other weirdness.
The script allows for another window manager, like Metacity, to be started whenever a Wine application is in use, and automatically starts Compiz or Beryl again after said application exits. As of version 9.9 of this script, you'll be automatically prompted if a program uses either OpenGL or DirectX, and the backup Window Manager is automatically detected.

In the same fashion, the script can also enable and immediately disable the "Legacy Apps" Workaround for Compiz Fusion, as it's known to break the fullscreen modes of regular apps.

#4 - Choppy performance, or stuttering sound.
The best workaround for the above is to change the nice value of both the wineserver and program being run to either "19" or "-10", which can get very annoying.
Fortunately, this script can do it for you; just use the "-n" command-line option to specify whatever nice value is desired. For nice values less than 0, though, you'll be prompted for a password, but it's only used for the "renice" command - nothing else in the script is ever run as root.

#5 - Applications changing the desktop resolution - and not changing it back. << thanks to Mikey for this one!

#6 - The mysterious .lnk shortcuts and .msi extensions
Wine is already able to handle these - it's just not very easy to figure out how. The script handles them automatically, and in the case of .lnk shortcuts, also asks if you'd like a proper menu entry to be created from it.

#7 - If a program crashes, and wasn't executed from a terminal, no indication is given as to why.
This script will show a window containing the last ten Wine errors if an application crashes:



If there were more, it also gives an option to view the entire log file. The script also warns of other common things, like bad paths and missing Wine drives.
Extended error reporting is also available by using the "-d 1" option, which saves error logs to the "log" folder of your Wine directory and shows all of the errors normally output by Wine - when this flag isn't set, only critical and system errors are shown. "-d 2" is also available, but it's mainly useful for Bug reports as it shows ALL errors and system calls.

#8 - AppDB integration!
When an application crashes, you'll be asked if you want to view it's Winehq Application Database entry, or if it doesn't exist, whether you want to create one. You'll only be asked once, but if you want to view the page again just run the particular app with the "-a" flag set. Unfortunately, this feature is currently limited to applications in the Wine menu.

If you want to test these out, Dwarf Fortress is a good choice as it's a small download and suffers from most of the bugs I listed above above - plus, it's pretty fun.

############
# Other Stuff #
############

Command line options:

Code:

All flags are optional
  -a	Displays a program's Application Database page if it has been added
	to the main menu.
  -c    Enable the "Legacy Apps" workaround in Compiz Fusion.
	Only available for the gconf backend.
  -d	Set to "1" to enable error reporting, as well as logging.
	Set to "2" to enable reporting of ALL error messages - This option
	mainly useful for error reports, as the peformance penalty is severe.
  -f	Force the Window Manager specified with the "-w" flag to be used.
  -l	Enables "Linux 32" compatability mode for 64 bit operating systems. 
  -n    The "nice" value that Wine applications are set to.
	"19" generally decreases application and sound stuttering, while "-10"
	can increase the performance of CPU intensive applications.
  -v	Set this to "1", or a specific resolution such as "1024x768", to create
	a virtual desktop. This is equivalent to checking the "Emulate a virtual
	desktop" option in winecfg, only on an application specific basis.
  -w    Specifies a backup Window Manager.
  -i	Prints version and copyright information about Winefix.
  -?	Displays this lovely usage message.

For example - `winefix -w metacity -n "-10" -c 1 Anacreon2.exe -e` would have winefix use Metacity, nice values of "-10", enable extended error reporting and logging, and start Anacreon with the "-e" option.

These options can also be permanently set as after the script is run for the first time, a file called ".winefixrc" will be created in your Wine directory - add whatever you like between the quotes. You can have one .winefixrc for every WINEPREFIX, or "bottle".

Changelog:

v 1.02: Disabled DRI and AppDB checks for setup files, fixed renicing via command line, fixed the deb package for Feisty users (sorry, that was terrible),.
v 1.0: AppDB integration, improved logic.
v 0.92: Added a .desktop file for better desktop integration, and Tango icons.
v 0.91: Added support for .msi and .lnk extensions, improved some logic, added the "-v" option to run apps in a virtual desktop, report "err" class Wine errors by default.
v 0.9: Make sure that if Wine changes the desktop resolution it gets changed back afterwords.
v 0.8: Added GUI error reporting and logging, and converted the script to /bin/bash.
v 0.7: Added command line options and usage information, and implemented proper passing of the WINEPREFIX variable.
v 0.6: For Compiz/Beryl users, added an option for another Window Manager to be run when a Wine program is in use.
v 0.5: Added support for Wine command line variables, and allowed for the nice value at which programs are run to be changed
v 0.4: Initial Release

hmmm interesting... did you post this on the winehq forums? Im still kind of up in the air with this but yeah good job!

To pass arguments in a bash script:
http://ubuntuforums.org/showpost.php...9&postcount=82
Is this what you were looking for? Hope it helps!

Originally Posted by dfreer

To pass arguments in a bash script:
http://ubuntuforums.org/showpost.php...9&postcount=82
Is this what you were looking for? Hope it helps!

Pretty close, but no . Thanks, though.

$@ spits out every command line variable given to both the script and Wine, while what was needed was a way to separate the two from each other.

I gave it a shot, and ended up using two grep commands, which work for most things:

Code:

arguments=`echo "$*" | grep -o ' -.*' | tr "\n" " "`
command=`echo "$*"| grep -o ".*\(exe\|bin\|msi\)"`

1 - Automatically renices both the wineserver and the app being run to 19. It seems odd, but Wine apps have serious trouble with the Linux scheduler, and lowering their priority is the only way to circumvent this.

heh, wow this does fix my sound in wow. not only that, but i think my fps is improved.

Originally Posted by graigsmith

heh, wow this does fix my sound in wow. not only that, but i think my fps is improved.

You know, I think you're right. Since the script now supports custom nice values, I did three tests using values of 19, 0, and -10, along with a control test that ran Wine without using the script at all. I used 3DMark2000 for the tests, and did three different rounds of testing on an up to date (~Tribe 6) install of Gutsy.

Here are the results as a graph...



and table, which also shows the average difference in performance over the control test:



This matches what I've experienced with other Wine programs, so it look like nice 19 really is the magic value, for both performance and increase in sound smoothness. Still, I'm planning to do a few more tests sometime soon on something more cpu than gpu or input intensive to see if the results hold, as nice -10 might have the edge in those instances.

Also: I updated the script again. I'll update the original post in a few minutes.

As promised, as few more tests - this time with Dwarf Fortress, a game surely able to bring the mightiest of CPUs to its knees (so to speak). I didn't use a frame capturing utility with this, so I recorded the maximum and minimum frame rates recorded during the intro movie.

The results are quite different from those of the last test:





A seen, nice 19 nearly halved performance, while nice -10 gave a slight (5%) boost. If these two tests apply elsewhere, it looks like positive nice values are beneficial to GPU heavy apps ( or those with sound skipping issues) while negative ones benefit CPU heavy ones.

If anyone else has been toying around with nice values, does this conform fairly well to what you've experienced? My system is pretty unbalanced in terms of performance ( a pretty decent dual-core AMD Turion 64 X2 TL-50 coupled with a weak Geforce 6100 ), so these results could be somewhat skewed.

Is it possible to have some sort of a configuration file that the script checks when launching an app, and picks the best values for it appropriately?

It would take some testing to figure out what the best value is in the first place, but If there's agreement as to what is best for a popular app it's definitely possible. It could be toggled with a command line switch, too, so at least it couldn't hurt.

That would be great. I'll try getting the script later and test on my machine