Home : Install a program that is not in the predefined prefixes with WineBottler (custom prefixes)

If you don't know what prefixes are, we suggest you first take a look prefixes.

With custom prefixes, you can create an app customized to your needs. This is most of the times a straight forward process, including selecting the installer and hit Install. But at times, if the windows application has special dependencies, there comes the hard part of debugging and troubleshooting the prefix.

Select the File to install

Here you select the file you would like to install. This is normally an exe or msi file. In combination with (2) it can be a cmd or bat aswell.

Copy only

If the file you selected in (1) is not an installer, but the program executable itself, check this box. The File will be copied straight into the new application and is preselected as the file that will be started every time you doubleclick the new app.

Prefix Template (optional)

Instead of creating a new empty prefix, copy a prefix and then install into the copied prefix. This comes in handy, if you repeatedly have to install the same dependencies, like say mono, that takes a lot of time to install. In this case it's better to install mono to a new prefix. Then select this prefix as a template every time you like to create an app for your .net application.

Winetricks (advanced)

 winetricks and  winetricks on winehq, does all the heavy lifting, when it comes to installing dependencies. Here you can select which additional dlls should be installed. Say you have a VBA Program that does not bring the visual basic runtimes, you'll add vb6run with winetricks. There are other nifty things you can do with winetricks, like changing the windows version or overriding certain wine dlls. But when it comes to using winetricks, just keep these two things in mind:

• No support will be given on  winehq to people using winetricks, as mixing native an wine libraries is very hard to debug.
• By installing a winetrick you are (more often than not) agreeing to a EULA. Consider this if you ever going to share the app you are about to create.

Self-Contained (optional)

So, You'd like to redistribute your windows app on OS X, but you don't like to instruct the customers to first download and install wine? Or your application needs a distinct build of wine? Just running with the latest wine may break things sometimes, as new bugs and features got introduced. Make it a Self-Contained app. This will copy your local wine runtime into the new app. Thus the package will grow considerably larger, but will run out of the box. The user needs to have an installed X11, which is a default since OS X 10.5. On OS X 10.4 you find it as an optional install on the installation dvd.

Native Dll Override (advanced)

Sometimes the wine dlls just won't run with your exe. In this case, you can override the builtin dlls with your custom dlls. Advanced reading on  winehq.

Setup Arguments (advanced)

Here you add the arguments that should be passed to the installer (exe or msi). This can be things like /q, /silent, /noreboot and are defined by the app you like to install.

Runtime Arguments (advanced)

Here you add the arguments that should be passed to the program every time it is started. These are normally stored inside the installed desktop link.

Runtime Version (advanced)

Give your new application a version, so you can distinguish them later.

Silent Install (advanced)

This will try to run all the installers in silent mode. No dialogs or EULAs will be shown. If you select this option, you must agree will all of them.

Now... debug, troubleshoot, debug, troubleshoot... or sometimes it might just run :D