Differences between revisions 82 and 83
Revision 82 as of 2018-10-03 13:23:02
Size: 4861
Editor: AlexKozlov
Comment: Remove ptrace issue fixed in 8.1; DOSbox from open tasks - native dos support was removed from wine
Revision 83 as of 2021-04-25 11:04:25
Size: 4901
Editor: KubilayKocak
Comment: Add relevent categories
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
On FreeBSD/i386 8.1 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 [[http://appdb.winehq.org|AppDB at WineHQ]] for the status of application support.   On FreeBSD/i386 8.1 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 [[http://appdb.winehq.org|AppDB at WineHQ]] for the status of application support.
Line 20: Line 20:
The FreeBSD kernel can be configured to detect a Microsoft Windows binary and to automatically launch Wine to run the Windows binary. This allows one to treat Windows binaries like normal binaries (i.e. no need to call `wine foo.exe`).   The FreeBSD kernel can be configured to detect a Microsoft Windows binary and to automatically launch Wine to run the Windows binary. This allows one to treat Windows binaries like normal binaries (i.e. no need to call `wine foo.exe`).
Line 35: Line 35:
For details please see the [[i386-Wine]] wiki page.   For details please see the [[i386-Wine]] wiki page.
Line 71: Line 71:

----
CategoryPorts CategoryVirtualization


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/i386 8.1 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.

Support for Wine/i386 on FreeBSD/amd64 is available in the emulators/i386-wine-devel port with unofficial packages provided by DavidNaylor.

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

Binary Image Activation

The FreeBSD kernel can be configured to detect a Microsoft Windows binary and to automatically launch Wine to run the Windows binary. This allows one to treat Windows binaries like normal binaries (i.e. no need to call wine foo.exe).

As root do:

# binmiscctl add wine --interpreter /usr/local/bin/wine \
    --magic "\x4d\x5a\x90\x00\x03\x00\x00\x00\x04\x00\x00\x00\xff\xff\x00\x00\xb8\x00\x00\x00" \
    --mask "\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff" \
    --size 20 --set-enabled

As CVE-2017-11421 a.k.a "Bad Taste" vulnerability has shown, it is possible to unintentionally execute malicious Windows applications in the presence of Wine, therefore automatic execution of what the kernel would find a "Windows binary", without explicitly invoking wine, can only facilitate such (unintentional) threat vectors.

32bit Wine on FreeBSD/amd64

For details please see the i386-Wine wiki page.

Open Tasks

  • add kqueue(?) support to server/change.c
  • port missing bits in dlls/ntdll/cdrom.c
  • copy protection support (securom, safedisc, etc.)
  • improve CPU feature detection (MMX,SSE,...) in dlls/ntdll/nt.c:fill_cpu_info()

More Wine Bug Reports

Known Problems

Address space organisation

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.

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

Mailing Lists

You can use one of the following mailing lists:


CategoryPorts CategoryVirtualization

Wine (last edited 2021-04-25 11:04:25 by KubilayKocak)