Ubuntu Wiki

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

• Created: 2005-12-04 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.

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

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.

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

• 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

• 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. We can still store (cached) icons for the applications menu in ~/.local like they currently are.
  • We should probably be extracting icons from every app we see and storing them in ~/.cache - tracker can perhaps be taught to do this.
• A user with an existing Wine installation will have many .desktop files calling Wine directly in his Applications menu. We will 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).

• Should not be in Applications>Windows>Internet submenu>eMule, if windows apps are delegated to itheir own directory they should fallow the windows de facto standard of a flat directory (although installers generally support changing this at install i dont know if wine supports this, t probably does), i generally think that windows should be seperate by default, mainly cause those apps are rarely supported, if those who made the apps care enough to integrate their app with the repos then they should be let to put there program menu with everything else (picasa is a wine app and does it)

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:

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

          • 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:

• 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

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

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:

• For security could wine be restricted by AppArmor. Maybe it could be it could be prevented from editing files outside the virtual C drive. This could reduce some of the possibilities of windows malware damaging things.

CharlesPax

• During the initial Wine configuration the user can be prompted to insert their MS Windows installation disk. The DLLs can then be extracted and copied to ~/.wine/drive_c/windows/system32.

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:

• Naming the desktop-shortcut "Windows C:\ Drive" is not ideal, since users might have a dual-booting system. Dual-booting does not remove the necessity for WINE, since you have the additional problem of logging out and rebooting, thus (temporarily) losing your primary desktop environment and most probably access to valuable data (e-mails, documents etc). Regarding the preferences, please think about adding an option for executing the Windows-app from its own folder. This is probably one of the issues that are usually responsible for a Windows-app not running. If it does not cause any problems, then this option could be set as default for all Windows-apps. As far as I know, WINE-Doors has this feature included, so maybe the code can be taken from there.

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/

• This is not a solution to slow theme problems. It's just a theming howto. -- AzraelNightwalker 2008-01-26 22:28:05

AzraelNightwalker:

• There is also one more use case that needs fixing: an app will not run under Wine not because Wine doesn't support it, but because it requires an installation of some runtime libraries (ie. MS Visual C++, MS Visual Basic). There are some tools that make their installation easier (winetricks, Wine-Doors) but they are not supported by Wine devs. See http://wiki.winehq.org/ThirdPartyApplications

CategorySpec