Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/better-integrated-wine/

• Created: Date(2005-12-04T01:43:27Z) by ScottRitchie

• Contributors: ScottRitchie

• Packages affected: wine, wine-dev, msttcorefonts, gnome (for autorun), some other package (for default handling without Wine)

Summary

We need a good, usable Wine to achieve a true competitor to Windows and solve bug #1. Wine needs a lot of usability improvements at the distribution level.

Rationale

Users want to run Windows apps, but this is currently too difficult in many ways. Users must first learn about Wine, then in many instances run it from the terminal after configuring it by hand. Many programs can be made to work using Wine, however the procedure is often so complex that users simply assume Wine is broken. By integrating Wine better with the Desktop, we both unify the user experience and make things "just work."

Use cases

• Joe Gamer wishes to switch to Ubuntu because he heard that it's faster and easier to use than Windows and he can run his latest games in it. To run Wine currently, however, he has to open most things through a terminal window and read several howtos on Google.
• Dan Developer hears that his open source Windows program works perfectly in Ubuntu under Wine, and wishes to support it more formally by creating a .deb package that depends on Wine, builds with winelib, and works on all Ubuntu-supported archs

• We can also use Wine as a basis to include other potentially very useful packages based on Windows software as part of universe or multiverse. When Wine matures enough to be in main, arbitrary Windows apps could be packaged into the partner repository as a very efficient way of porting to Ubuntu. See, for instance, EmuleViaWine spec.

Scope

This specification covers both the Wine package as well as things we can do at the system level to make things easier on the Wine user.

Design

Nautilus and Gnome

The user will be able to install Wine easily by selecting "Wine Windows Compatibility Layer" from Gnome-app-install. Once done, this enables a new program group in the applications menu called "Windows"

If the user doesn't have Wine installed and attempts to double click an executable (with or without the execute bit set), they will be notified and asked if they want to install Wine in much the same way a user is prompted to install Samba when they launch the shared folders applet.

Once Wine is installed, Windows applications will be given a Wine icon. Right click should present an "open with Wine" option, however it will not be the default upon double-click.

The Windows Program Group

Once Wine is installed and the user has installed some Windows applications, the user can then select Applications->Windows, where his virtual Windows start menu will reside. Currently, upstream creates a Programs subfolder (representing Windows Program Files)

System->Preferences->Windows Applications

Here we reimplement only the Wine configuration options we need.

• (Pulldown menu): "Default Windows version to emulate when launching Windows applications"
  • Windows 2000 is currently the upstream default, which works for most apps
• (unchecked by default) Automatically launch applications upon inserting a disc
  • This is where the user can disable autorun by default if he enabled it with the checkbox in the autorun prompt
• (radio button default): Allow full screen applications to change the resolution
• (radio button alternate): Contain full screen applications in a window when smaller than the desktop
  • These are the two main use cases of Wine's various Window managing options. The latter might not be fully functional in time for Hardy.
• (button) Advanced

  • Launches winecfg, or a similarly functional GTK application. We can consider removing this when Wine's defaults get good enough, however likely not by Hardy. To reimplement the configuration we need in GTK requires some upstream changes (see http://wiki.winehq.org/ConsoleConfiguration ConsoleConfiguration on Wine's wiki.

Wine uninstaller

The Wine uninstaller program can have its functionality integrated into gnome-app-install. We add a "Windows Applications" category on the left for Wine apps, except those installed with packages that aren't on the Wine menu. Note that removing these will not require a password.

This requires an upstream change in Wine for it to export metadata about what apps are uninstallable, as well as some new code in gnome-app-install to handle wine uninstalling. We will also need to modify Wine to support the command line. See http://wiki.winehq.org/ConsoleConfiguration Console Configuration on Wine's wiki.

Autorun

When a CD with Windows autorun is inserted, the user is presented with a prompt asking if they want to browse the CD or launch the autorun application. If the CD also has music on it, the user is presented with 3 options (browse CD contents, play music, or launch autorun application). If the user does not have Wine installed and chooses to launch the application, he is then presented with the same "You need to install Wine" dialog as if he tried to launch an executable by double clicking. Implemented here: autorun

Fonts

Wine comes with several fonts for Windows compatibility. Fonts that are "full featured" (ie, have features like bolding and italics working) will be split out into a wine-fonts package. The rest will remain hidden from the system and internal to Wine.

Theme

Wine's default theme should be set to match the Ubuntu default theme. Currently, Wine doesn't know how to read the Linux theme, so if a user changes his theme then Wine will still look like it did originally unless Wine is also configured. Due to the vast differences between GTK and win32, simply reading and interpreting the system theme directly is likely impossible.

We can, however, ship a Windows theme that matches our own and set Wine to use it. See, for instance, [WineHumanTheme].

Unfortunately, Wine's theming support is quite slow at the moment, mostly due to problems with alpha blending. If upstream Wine doesn't support theming properly by UserInterfaceFreeze, then we'll use Wine's default theme but instead change the colors to match. The proper way to change the colors is by making our own .msstyle file.

Documentation

Wine's documentation is kept separately upstream, and needs to be packaged and made a dependency of Wine. Wine's documentation is currently in obsolete SGML format, unsuitable for use with Scrollkeeper and the Gnome help menu, so it must be ported to XML with a proper .omf file being made - these changes can easily be passed upstream.

Implementation

• None yet. Most will be done by ScottRitchie, the Wine maintainer, however some of the gnome-specific changes will require help from Gnome upstream.

Outstanding issues

• Theming support in Wine is still slow

• [http://wiki.winehq.org/ConsoleConfiguration Console Configuration] in Wine is not yet implemented

BoF agenda and discussion

• Discuss eight ways to open an executable (with/without Wine):

• The same issue applies to msi files. Should msiexec /i be considered equivalent to .exe running (this is the default action for double click on Windows)

• Fonts
• Gnome-app-install
• Changes needed to winecfg, wine uninstaller

• Right click->Properties

• Theming
• Wine + Mono integration
• Wine + Gecko integration

Result

• We don't ship MIME entires for Wine.
• Hit the 90% by covering win32 (not win64) for the moment and only on i386 (for the moment).
  • Though most all of this works equally well in 64.
• Make the .exe experience the same as for ELF binaries. No worse, no better.

• Leave all execution to the binfmtmisc handler.

• Have a MIME handler that can allow the user to chmod +x---this could be done for non +x'ed.

• Try to pull the Windows .ICO out of the executable.
  • This can be done with icoutils package
• Currently nautilus has a useless "codec not available" message for -x'ed execs.

• .msi (non-executable package file). Open with msiexec. This is not a security issue until the user runs the file

• apport equivalent for crashing/failing win32 applications would be nice
• Fonts:
  • Split out good fonts as a separate package
  • Leave "compatibility" (just enough for run) fake fonts

• Have Free Software available win32 software packaged in universe with a dependency on wine as an example for developers to follow (see EmuleViaWine)

• Wine Config
  • Turn winecfg into a backend-front end application so we can have commandline and KDE-based front-ends.
  • Really winecfg is superflous.
  • Only use case is select a different version of MS Windows to emulate.

    • alternatives / PATH might be better (think multiple python, java, or GCC installs)

  • Move to System->Preferences->MS Windows

    • Actual relevant options are:
      • Emulate version {2k / XP / 98 / 95 ...}
      • Rootless / Windowed mode (Size width, height)
• Browse C:\ drive
  • Move to Places menu (desktop entry to GNOME favourites?)
    • Talk to the Gnomies about this
• Gecko duplication (for "Fake IE" / HTML widget)

  • Ask upstream if they can dlopen() and use the local Gecko rather than a second copy. (And maybe local mono).

    • If not, need to modify the source code and build another copy with mingw32.

• Fix Wine msiexec so that menu items links are made to the executable

  • Investigate winefix

  • Have the wine interpreter check the registry for the working directory for the executable.
  • Which could also be set/overridden with right-click propeties.
• Get the Wine defaults to the best defaults
  • Select the
  • Move "Wine Uninstall"

• Applications->Wine->Programs->Accessories-> (result of any application calling the Menu method)

  • Move
  • Top-level Start-menu entries, move across to always be inside "Programs"
• "How do I run wine?"
  • The populated "Notepad" entry solves this and gives users a hint.
• First time "creating your .wine"
  • Have a dialogue progress "Creating your virtual Windows machine".

• Upgrades, may have to re-run wineprefixcreate

  • Store a wine stepping in ~/.wine and bump on upgrade.

Automatic install of wine

Nautilus and gnome-app-install have some magic to suggest applications for file-types that it does not known how to handle. gnome-app-install has a database where it searches for applications that can handle this mime-type. Currently this does only work for main,restricted (because of the security support from canonical). To make this happen with wine, either the /etc/gnome-app-install/packages-whitelist or edit the gconf key "/apps/gnome-app-install/mime-whitelist-components" to include "universe".

Old Comments

Warbo: Just a small point, but Applications>Windows>Program Files could merely be Applications>Windows as nothing other than programs should be in the "applications" menu. Preferences and configs should be in the System>Preferences menu. Also, once WINE has matured a little and perhaps has some GTK/QT wrappers for it's interface there should be nothing wrong with seeing WINE as a legitimate platform for creating programs, just like Mono is now. Therefore, eMule would no longer be in Applications>Windows>(maybe "Internet submenu?)>eMule, it would just be in Applications>Internet>eMule. I think it is important to remove the distinction between FLOSS Linux programs and FLOSS Windows programs to keep the menus managable for novice users. There may be outcry at this integration of Windows programs in Ubuntu, but I see it as "the user's programs" rather than "Windows programs", and it increases the choice available. People may say that Windows programs are badly made, but if that is the case then users will begin to recognise this and perhaps use XMMS instead of WinAMP (I know it is not Free, but I don't know of that many Free music players for Windows) but they will still be able to use their specialised Windows software which has no Linux alternative. The vast number of Windows applications means that they cannot be ignored. As long as only FLOSS programs are put into Universe then the moral arguments are gone and Windows users are left with no "my programs won't work" excuses for not using Ubuntu. To really make this possible WINE needs to transparently create packages of anything being installed through "Install Shield", etc. to allow proper integration with the system and, most importantly, making it very easy to remove software completely later, (this should not be too hard, since WINE runs in a virtual environment allowing complete control over all of it's actions).

Ubuntu is currently a far better system than Windows, and must not be brought down in order to appease new converts, but instead Ubuntu should be extended through WINE without giving up it's principles of freedom. That would make it a far better alternative to current Windows users, who may not "get" Ubuntu's philosophy but who can still be converted due to price and performance. Also, integrating Qemu bin-fmt support would allow this integration of WINE for most platforms (x86/amd64, PPC, SPARC, etc) and in the long term, as more and more people leave Windows behind and break the catch-22 of "people use Windows so we develop for Windows. People develop for Windows so we use Windows" then the mainstream hardware market can start to actually invest in newer technologies (I know IBM already do) and then Windows users will finally realise the lack of support they have suffered all these years due to vendor lock-in (only Windows programs will run and only on x86). I know I will get flamed for this, but feel free to offer comments

Warbo: Here are some relevant points made in the CommunityEdgyIdeas/WindowsCompatibility page:

Better wine integration

• Add wine programs to the GNOME menu like Xfce or KDE does.
• Or make wine create shortcuts like linux programs do.
• Wine's C:/ Should be added to the nautilus Places. Since this directory is hidden in the system, it's otherwise hard to browse to.

ArtemVakhitov: speaking of fonts, one case should be specifically handled when a user installs a Windows application in Wine whose locale is different from the current one. For example, when I try to install MS Office 2000 Russian edition on C locale, I'm getting unreadable fonts. This can be worked around by prepending wine call with LC_ALL=ru_RU.utf8, but even this for some reason doesn't work reliably in all places. This may be Wine bug, but since there are ways to mitigate it, I thought I would mention this.

New Comments

AzraelNightwalker:

• Maybe you could use Wine-Doors in this spec? http://www.wine-doors.org/

• What about Windows viruses? I'm afraid that implementing this spec could make Ubuntu prone to them.

KrisMarsh:

• I think re-implementing winecfg using GTK would be a bit pointless. Providing there is a Ubuntu-like theme for Wine, we should be ok. Granted, it will be a bit slower to start up - but then we may want to look at optimising it's start up.
• Providing Wine skinning support is optimised (actually, it's specifically alphablending for small tiled gradients that is slow - we should be able to write a Ubuntu-like theme that works fast enough, regardless of whether the skin slowness is fixed).

• How does one help out?

CategorySpec