This is an old revision of the document!



Porting Wine to FreeBSD

Wine is an open source implementation of a Windows application environment, which allows running Windows programs on other operating systems.

It is a complex piece of software, that relies on various parts of the underlying operating system. This page is meant to collect various bits of information about Wine on FreeBSD to assist in porting.

On FreeBSD/i386 8.0 and later Wine should work for most user applications including Microsoft Office 2007. Games tend to be more problematic, but many work without issue. See the AppDB at WineHQ for the status of application support.

Although there is no official support for Wine/i386 on FreeBSD/amd64 there are packages available from MediaFire that support FreeBSD 8 and later. For more details see the following section.

If you run into bugs, feel free to file a bug report in the Wine bugzilla and mention the version of FreeBSD you're using.

Wine requires LDT support, but it is not available on RELENG_7 and earlier versions. This is fixed in 8.0, r190620.

FreeBSD currently lacks support for 32bit ports on a 64bit system however an unofficial port exists that will compile a wine package under 32bit FreeBSD that can be installed under 64bit FreeBSD. The patch (called wine-fbsd64.diff) and packages for FreeBSD 8, FreeBSD 9 (wine versions 1.3.16-37, 1.4 and 1.5.0 - current) and FreeBSD 10 (wine versions 1.5.2 - current) are hosted at MediaFire. 3D acceleration using the proprietary nVidia driver is supported, see the package message when installing the package for details. An email gets sent to the freebsd-question and freebsd-emulation mailing lists when a new version of wine is available.

A second approach is to, with a little bit of effort, build and use the 32 bit wine executable from a /compat installation of FreeBSD/i386:

# cd /usr/src 
# make buildworld   TARGET=i386 DESTDIR=/compat/i386
# make distrib-dirs TARGET=i386 DESTDIR=/compat/i386
# make distribution TARGET=i386 DESTDIR=/compat/i386
# make installworld TARGET=i386 DESTDIR=/compat/i386
# chroot /compat/i386
# /etc/rc.d/ldconfig start
# mount -t devfs devfs /dev
# mkdir -p /usr/ports; mount nfs:/usr/ports /usr/ports  (or mount it via nullfs from outside the chroot, or just copy everything over)
  1. set the environment
# setenv MACHINE i386
# setenv UNAME_p i386
# setenv UNAME_m i386
# cd /usr/ports/emulators/wine && make install clean
# exit
  1. Use something like the following aliases
alias winecfg="LD_32_LIBRARY_PATH=/compat/i386/usr/local/lib PATH=/compat/i386/usr/local/bin:$PATH /compat/i386/usr/local/bin/winecfg"
alias wine32="LD_32_LIBRARY_PATH=/compat/i386/usr/local/lib PATH=/compat/i386/usr/local/bin:$PATH /compat/i386/usr/local/bin/wine"
  1. For sound in Diablo 2 to work, run winecfg and set DirectSound acceleration to “Emulation” (see Known Problems section above) then run “wine32 Game.exe”
  2. 3D acceleration is working with the 64bit nvidia driver provided that you install the 32bit version (same version number) into the chroot.

Alternatively, there is a third way described here: http://www.daemonforums.org/showthread.php?t=4708

  • add kqueue(?) support to server/change.c
  • port missing bits in dlls/ntdll/cdrom.c
  • copy protection support (securom, safedisc, etc.)
  • DOS support - partially supported through DOSBox if installed
  • improve CPU feature detection (MMX,SSE,…) in dlls/ntdll/nt.c:fill_cpu_info()

The address space of a wine process under FreeBSD/i386 looks roughly like this:

0x00000000-0x00110000 DOS area
0x00110000-0x60000000 available for Windows exe, DLLs, thread stacks, heaps,…
0x60000000-0x6000???? wine executable
0x6000????-0x6200???? about 32MiB libc malloc(3) heap (since FreeBSD 7.0 malloc(3) can use mmap(2) as well)
0x6200????-0x7ffe0000 unreserved, available to load libs (libc.so, libm.so, libX11.so,…), Wine DLLs (ntdll.dll.so, kernel32.dll.so,…) and other mmap(2) calls in code outside Wine (e.g. graphics drivers)
0x7ffe0000-0x82000000 reserved by wine
0x82000000-0xbe?????? unreserved, available to load more libs, Wine DLLs and other mmap(2) calls in code outside Wine (e.g. graphics drivers)
0xbe??????-0xc0000000 main wine process stack
0xc0000000-0xffffffff FreeBSD kernel address space

This seems to mostly work, but the problem is that it's possible for Wine DLLs to be loaded beyond 0x80000000, which (by default) isn't user address space anymore on Windows and this could confuse some programs. On Linux this problem doesn't exist because Wine reserves everything beyond 0x80000000 and mmap allocations go downwards in memory. On Linux mmap can allocate space below 0x60000000 when needed. On FreeBSD addresses above 0x80000000 are not reserved, because mmap allocations go upwards starting after the malloc heap and there would only be about 480MiB available otherwise which is not always sufficient.

At this point the main reason copy protection schemes like Securom and Safedisc don't work is that ntdll.dll.so and kernel32.dll.so aren't loaded at the right address. On Linux these libs have a specific base address (0x7bc00000 and 0x7b800000 respectively), but the FreeBSD ELF loader doesn't support base addresses for libs (only for programs).

(This has been fixed in FreeBSD 8.1.)

There's a race in the FreeBSD ptrace(2) implementation that causes Wine to hang sometimes. A typical example is winedbg hanging. This also causes a test failure in dlls/kernel32/tests/toolhelp.c.

More info: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-August/021430.html

You can use one of the following mailing lists:

  • wine.1355882671.txt.gz
  • Last modified: 2012/12/19 02:04
  • by SteveWills