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.

Status

On FreeBSD 7.0 and later versions, Wine should work for most user applications. Games tend to be more problematic, but it's worth trying.

For FreeBSD 6.3 and later patches are available below.

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.

Open Tasks

freebsd-amd64: Some Windows apps use the segment registers (%ds, %es, %fs, %gs), but these registers aren't preserved during context switches on 7.0 and earlier. This is fixed in RELENG_7 and head. (see also this email)
add kqueue(?) support to server/change.c
sound support, specifically with hardware acceleration set to full in winecfg (see wine/9599)
improve CPU feature detection in dlls/kernel32/cpu.c (see wine/17713)
port missing bits in dlls/ntdll/cdrom.c
copy protection support (securom, safedisc, etc.)
DOS support (vm86)

More Wine Bug Reports

Known Problems

Sound support

Sound output is often garbled. If that happens to you, run winecfg, and at the bottom of the sound tab, try to set hardware acceleration to emulation instead of full.

Address space organisation

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

`0x00000000-0x00110000`	DOS area
`0x00110000-0x7bf00000`	available for Windows exe, DLLs, thread stacks, heaps,...
`0x7bf00000-0x7bf0????`	wine executable
`0x7bf0????-0x7df0????`	about 32MiB libc malloc(3) heap (since FreeBSD 7.0 malloc(3) can use mmap(2) as well)
`0x7df0????-0x7ffe0000`	about 32MiB 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 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 0x7bf00000 when needed. On FreeBSD mmap allocations go upwards starting after the malloc heap and there's only about 32MiB available there which has turned out not to be enough for some (graphics intensive) applications.

Copy protection schemes

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

Race in ptrace(2)

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

Wine on FreeBSD/amd64

FreeBSD currently lacks support for 32bit ports on a 64bit system. However, with a little bit of effort you can build and use the 32 bit wine executable on an amd64 system (Diablo 2 works just fine). The following list is not minimal, as I tried several different paths before I got one working.

# cd /usr/src && make buildworld installworld distribution 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)

set the environment

# setenv MACHINE i386
# setenv UNAME_p i386
# setenv UNAME_m i386

# cd /usr/ports/emulators/wine && make install clean
# exit

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"

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"

I could not test 3D acceleration lacking a supported card. If someone could test these, please add your findings.

Patches

FreeBSD patch for FreeBSD 6.x: patch-fbsd-6
After downloading this patch follow these instructions. You need to be familiar with building world and kernel as described in the FreeBSD handbook.
1. Apply the patch to your source tree:
```
cd /usr/src
patch < /path/to/patch-fbsd-6 
```
2. Recreate syscall info:
```
cd /usr/src/sys/compat/freebsd32
make sysent
cd /usr/src/sys/kern
make sysent 
```
3. Rebuild and install world and kernel:
```
cd /usr/src
make buildworld buildkernel
...install kernel and world as described in the handbook... 
```
4. Rebuild and install Wine:
```
cd /usr/ports/emulators/wine
make deinstall clean install 
```
Wine patch for FreeBSD 6.x: patch-large-heap
Due to the way Wine is setup it is possible that graphics drivers run out of malloc heap space on FreeBSD 6.x when using 3D acceleration. If you see error messages like "Memory allocation failed" or GL_OUT_OF_MEMORY or similar you could give this patch a try. Simply put it in /usr/ports/emulators/wine/files and rebuild and install Wine.

Mailing Lists

You can use one of the following mailing lists:

freebsd-emulation@freebsd.org: Wine topics specifically related to FreeBSD.
wine-devel@winehq.org: General Wine developers mailing list.
wine-users@winehq.org: General Wine users mailing list.