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

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.

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 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. Alternatively, we can make our own theme that simply lacks alpha blending.

At the least, we can set a color scheme that matches the user's Ubuntu theme (http://www.endolith.com/wordpress/2008/08/03/wine-colors/)

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.

How to open exe

Wine installed

Wine not installed

Double click in nautilus with execute bit set

Run application with BINFMT, it loads Wine

Show a dialog saying that this is an executable and that the user needs Wine to run it, optionally allowing download

Double click in nautilus with execute bit not set

Show a new dialog saying that "Foo.exe is an application. In order to run it you must first give it permission to execute. (Cancel / Launch Application)" Cancel closes; Launch application chmod u+x's and runs the program.

Show a dialog saying that this is an executable and that the user needs Wine to run it

By inserting a CD with autorun

Do you want to autorun?

Give the same do you want to autorun box, however if user hits yes then give the requires Wine prompt above

By downloading with Firefox

Do nothing, wait for user to double click it on desktop

Do nothing

Download with Firefox (From the downloads window, clicking open)

Open (note that this will not execute until launch is clicked, since execute bit isn't set yet)

Same as in nautilus

By opening with Evolution

Do nothing

Do nothing

By running an Applications Menu link

Open with script that sets working directory properly (eg winefix)

Prompt to install Wine (note this is possible if user has removed Wine but didn't uninstall applications)

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.

Gecko integration

Wine now supports installation of the gecko libraries (for its fake internet explorer implementation) by using a local file rather than downloading it over the internet. We should ship this cabinet file, however building it on Linux may be nontrivial.

Mono integration

.NET applications that also use Windows-only functions cannot work using mono alone. However, the combination of the Windows version of Mono and Wine can run them. For this reason, we should bundle a Windows version of Mono alongside Gecko.

Implementation

Outstanding issues

BoF agenda and discussion

How to open exe

Wine installed

Wine not installed

By double clicking in nautilus

?

Show a dialog saying its an executable and informing the user about Wine

By inserting a CD with autorun

Do you want to autorun?

Do nothing? Or prompt about Wine?

By downloading with Firefox

Do nothing for now

Do nothing

Download with Firefox (Downloads->Right Click open)

Do nothing

Do nothing

By opening with Evolution

Do nothing

Do nothing

By running an Applications Menu link

Open with script that sets working directory properly (eg winefix)

? (note this is possible if user has removed Wine but left apps)

Result

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".

Dialog text

Modified from https://bugs.launchpad.net/ubuntu/+bug/164209

The Install Wine button would open Add/Remove programs (will be PackageKit in the future?) with Wine already selected and applied to encourage understanding of the Add/Remove app.

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 Smile :)

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

Better wine integration

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:

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

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

    • ScottRitchie:

      1. 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.

      2. 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.

        AzraelNightwalker:

        • Maybe we could install clamav with wine and make it scan every .exe before running it?

        • Currently wine sucks at running windows viruses but this may change in the future Wink ;)

          • JonasJørgensen:

            • clamav: Please don't. "Virus scanning" provides more false-sense-of- than actual security, and we don't want to help propagating the myth that anti-virus programs are an acceptable solution to Windows' security problems.

              • JohnMccabeDansted:

                • Although fairly ineffective against day-zero attacks, Virus Scanners are still pretty effective against old viruses: http://www.heise-online.co.uk/security/Antivirus-protection-worse-than-a-year-ago--/news/100900

                • ... So running clamav should be effective for CDs, software on old Windows partitions etc. Definiately better than nothing.

                • A more robust solution would be to sandbox the windows app. There is also clever trick where you can override the GTK file open dialog box, so if the user opens a file via the file open dialog box, the app gains the right to access this one file http://plash.beasts.org. In principle this could mean that the user doesn't even need to notice that the app is sandboxed. It may be possible to likewise override comdlg32.dll http://support.microsoft.com/kb/161286; this clearly wouldn't help much for apps that bypass comdlg, but I don't know how common they are.

        Tacone:
        • Adding a warning in the confirmation box would be useful: "This is a Windows program, since most virus affect windows market the danger is higher. Only run Windows executables coming from trusted sources/sites". (reformulate as you wish)

KrisMarsh:

KrisMarsh:

KrisMarsh:

LoyeYoung:

  1. The theming integration should, IMHO, be done in a manner similar to wineconfig, which is a python script running as a part of KDE Guidance that changes various settings that Wine uses. It has some overlapping functionality with winecfg, but wineconfig can do things that winecfg cannot, like read your desktop color theme settings and make wine conform so that it's not as ugly. Perhaps we could call the new package wineconfig-gtk, with dependency to a wine-theme-ubuntu package, if desired. Advantages to creating a wineconfig-gtk are:
    • Fewer changes to wine itself so that updates from upstream can be backported quickly and easily;
    • Won't conflict with wineconfig "classic"
    • Allows users to run Windows apps in a Windows look-and-feel window, which in some cases may be preferred by some people.
    • Would be more extensible.

    • YuriyKozlov:

      • While not absolutely vital, Console Configuration through winecfg should really be implemented before any more work on wineconfig-kde or -gtk

      • Need to work together to figure out what settings are actually needed in such a utility and how to organize them, and on creating a common back-end.
      • Current implementation of reading your desktop color scheme isn't ideal because it doesn't keep it in sync, and theming functionality is not entirely implemented in wineconfig.

        • ReeceDunn: I have some patches being applied to wine that improve winecfg behaviour. I have it such that with those patches, winecfg can import a theme file's colour scheme correctly such that it can load a ubuntu theme file. I think the best way to go is to fix the usability bugs in winecfg to make it usable, make it provide Console Configuration facilities and work with the Wine developers to make upstream Wine better for everyone instead of writing another configuration tool that does the same thing.

  2. As a system builder, I too am very concerned about throwing the baby out with the bathwater when it comes to having .exe association to wine. I don't think it's sufficient just to say that a program will be run and providing an OK / Cancel option. At install time, I'd want to have more explicit warnings and a challenge/password/confirm routine, and after install whenever the program is executed, at least a password and a warning to the effect of "Windows-Based Software Warning: The Ubuntu community cannot ensure that proprietary software programs are secure or work properly because proprietary software typically hides the software source code. If you know the program you are starting is safe and are willing to be responsible for any problems the program may cause, click OK below. If you know that the program is not secure, or are uncertain whether it is safe or not, click Cancel. "
  3. Scott, your remarkable and dedicated work to the Ubuntu wine project is greatly appreciated by many people, myself included. Many Thanks.

ScottRitchie:

  1. Agreed, I'll be taking a look at wineconfig for KDE soon.
  2. When the user clicks "Launch application" after opening an application, that is a very clear message the user wants to run the application. Attempting to stop them after that simply gets the interface in their way - why not take that to its logical conclusion and simply prevent applications from running? As for password prompts, there is absolutely no need to do this since nothing in Wine is ever running as root. We don't want to turn Ubuntu into Windows Vista and get users in the habit of ignoring security warnings (or even disabling them entirely). The last thing I want to see is a rash of forum posts advising users to chmod 777 -r their entire home directory.

  3. Thank you, very kindly. I don't get paid to do any of this, so I'm running on pretty much good will at this point and every bit helps Smile :)

JeromeHaltom:

  1. I sure wish Wine acted like Windows. You know, centralized HKLM and Program Files. Per-user HKCU and stuff. Installing stuff like Steam on a multiuser Wine box is idiotic. Each user gets his full private copy of 40GB of games. Waste of space. I'd like to see the C:\ drive be put into something like /var/wine/c, applications able to be installed by the package management system into /usr/lib, and per user My Documents/registry forks in ~. Windows has all of the appropiate APIs to make this work, since NT4.
  2. Really, this could be done very nice. Default wine package could build /var/lib/wine/c. Wine distributed files could be installed into /usr/lib, and symlinked into C:\WINDOWS. Registry could be split into two forks... it already is. One could live in /var/lib/wine/system.reg, the other in ~/.wine/user.reg. The only missing parts would be the likely unimplemented permissions on registry pieces (HKLM should not be writeable except by a user in the wine-admin group, for instance). That'd probably require two wineservers... one for the per-user registry fork, the other for the system. So, that's a bit difficult.
  3. A configuration like this would make distributing Windows applications to an Ubuntu network pretty awesome, too. I could build .deb packages for my Windows applications, declare that they depend on 'wine', and install them into /usr/lib. Post-install script could add required registry entries just like on any Windows setup.exe I would build. Then I could push these applications out with Apt. Our company has a lot of old VB and MFC applications which we use internally. They run on Wine, but distributing them to users has always been a challenge.

    • KrisMarsh: All valid points I think, but I don't believe this is within scope for this specification (feel free to correct me if I'm wrong). You are encouraged to raise a bug/enhancement against either Ubuntu or Wine (or both!), so we can track and implement this. Alternatively, it might be worth creating another specification.

    • ScottRitchie: I definitely share your desires. Unfortunately, Wine doesn't really support per-user registry forks right now - the /var/lib/wine/system.reg file is simply copied into ~/.wine when wineprefixcreate is run. This is giving me a bit of an idea though: why not have the system-wide Wine at C:\ (in /var/wine/c) and then have the per-user stuff at D:\ (in ~/.wine/drive_d) - Aside from the upstream changes, we'd need a way to figure out how to make this usable, though. This process would make things more complicated on a single user desktop unless we made a tool that allowed them to migrate their single-user ~/.wine installation to a multiuser one.

SamTygier:

CharlesPax

Vexorian:

  1. No script or executable seems to be able to run from nautilus automatically from double click even if it has the executable permission, it always prompts a confirmation dialog, in my opinion it should be the same for WINE this way we wouldn't need the executable permission either. (Some non-ext3 disks probably will never easily have it)
  2. Regarding theming, WINE lately allows you to customize colors from GUI, it would be good enough to ship it with some human theme and let the user do the remaining customization, QT apps suffer the same problem right now and it isn't a critical deal.
  3. "Wine Windows Compatibility Layer" is a very long name
  4. In my opinion, run by double click will not really help users so much, a lot of WINE programs need much more tweaks than just opening a terminal and prefixing the executable file with WINE (for example some of them require a no-cd crack) and letting users think they are supposed to be able to run win32 apps in ubuntu is going to be deceptive.
  5. Regarding icons, I think it should either keep the WINE executable icon or be able to form a custom icon some how, the optimal solution would be having some generic WINE app icon and adding the .exe's icon as an emblem.
    • deeesseee: Why would it be Wine for the icon, with the .exe as the emblem? It should be the other way around. The person is more interested in running that specific exe, and the emblem lets them know they'll be running it in Wine.

Sokraates:

foerdi: http://www.playonlinux.com/en

PierreSlamich: There is a slick solution to slow theme problems: http://tombuntu.com/index.php/2008/01/04/stop-wine-from-beating-your-windows-apps-with-the-ugly-stick/

AzraelNightwalker:

The dialog that pops up when you try to run a .exe will give a brief introduction to Wine and explain how some programs work better than others, so that they do not have false expectations.

When running a program results in an error, it should be displayed to the user (maybe hidden in a fold-out for minimal intimidation?) along with a clear message about how to use the error message to report a bug and get help online.

CategorySpec

BetterIntegratedWineSpec (last edited 2009-02-17 15:03:27 by pool-96-224-69-176)