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.

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.

Running Applications

In general, Wine applications will be handled the same as ELF binaries with regard to security. We prevent the possibility of running applications accidentally, however once the user has expressed the intent to run the application by setting the execute bit we launch it with BINFMT.

Two different cases occur depending on if we have Wine installed.

On First Run

When Wine is first run, it takes a good amount of time to setup the ~/.wine folder using wineprefixcreate. Here, we should modify upstream Wine to create a D-Bus message saying that wineprefixcreate is running, which Gnome then listens to. When Gnome sees the message, it displays an indicator saying "Please wait while your fake Windows installation is created. You can access it from the Places menu." This then creates a .desktop entry in Gnome favorites called "Windows C:\ Drive"

Adding applications to the Start Menu

Currently, Wine adds applications to Applications->Wine->Programs, representing Program Files in the Windows start menu.

We will simplify this, squishing Programs into the main Wine folder and renaming it "Windows" so we just have Applications->Windows. In the rare event that a Windows application asks for a shortcut to be put above the Program Files folder (this is possible in Windows), we will simply treat it as though it were in the Program Files folder.

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

• Windows executables can have embedded icons, however we currently do not extract these and display them. For now, we default to the Wine icon, however icoutils could be used to display them. This may be something fairly simple for nautilus to do, and it would in fact be necessary to implement otherwise we will break icon functionality in the Wine Applications menu.
• A user with an existing Wine installation will have many .desktop files calling Wine directly in his Applications menu. We should probably leave them alone.

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
  • 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 know 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.

ScottRitchie:

• Some of Wine doors may be useful by release time, some might not be. We'll have to see where Wine is at that point. Remember that Wine doors is essentially workarounds for applications that can be made to work with Wine but don't install properly yet. As Wine fixes Wine bugs, wine-doors gets less useful (much like how WineTools is useless now). If it's still useful after a few months, at the very least, I'll make a good .deb package of wine-doors and get it into the repository.

• We're very aware of the dangers of running viruses. That's why applications don't execute on double click unless the user has either manually marked them as executable or done so through a dialog after being informed that it's a program. This way we stop all accidental viruses except for trojans that the user specifically asks to run - and those we cannot stop unless we completely take away all functionality.

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.

ScottRitchie:

• The idea is to reduce wine configuration from the complicated mess that winecfg is to something that's only a couple of options. Upstream winecfg will always, for instance, have the sound driver selector; we can hide that relatively useless option from the user and just pick a sane Ubuntu default. Since we're redoing it anyway, it might as well be GTK.

KrisMarsh:

• 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).

ScottRitchie:

• That's a very good idea, actually. We could just edit the slow parts out of our Windows theme if we have to.

KrisMarsh:

• How does one help out?

ScottRitchie:

• Soon (possibly after a week or so) I'll be formalizing the Wine team and making it into a truly collaborative effort. There'll be a nice list of ways to help. You can always, of course, help with Wine upstream

CategorySpec