Wine on Windows

This page is about trying to get Wine to run in Windows. Many Wine DLLs can be cross-compiled with MinGW already, but Wine itself doesn't work yet.

Why would we want to get Wine running in Windows? Newer versions of Windows fail to support old applications that are still supported by Wine. So Wine for Windows would supply useful backward compatibility for users.

A working Wine on Windows is way into the future. In the meantime, it helps keep Wine robustly cross-platform!

(The real reason, of course, is that it's obviously evil and wrong and therefore fun for hack value.)

The main POSIX interfaces for Windows are:

  • Cygwin
  • MinGW
  • Interix (Windows Services for Unix)

You may do better cross-compiling on a fully kitted out GNU/Linux box than on Windows. Xming certainly doesn't compile on Windows, for instance.

Problems

To get Wine working on Windows will require lots of work.

  • The Wine program loader will not work with Windows. This must be fixed before this effort can work.
  • StevenEdwards 1 2 suggests the POSIX layer will need to emulate POSIX sendmsg/recvmsg. (Interix doesn't in SFU 3.5, Cygwin claims to. sendmsg/recvmsg implementations in Cygwin don't support file descriptor duplication between processes on which wineserver depends upon)

  • RoderickColenbrander notes: "Cygwin/Mingw doesn't work due to missing functionality for wineserver I believe (not sure what)."

Good things:

  • The DirectX implementation should work on Windows with some tweaking already. (Wined3d is already used commercially in Parallels to pass DirectX through to OpenGL. See wiki article on WineD3DOnWindows)

  • The Wine test suite should already build under MinGW.
  • You can compile Wine DLLs for use on Windows using MinGW - see binaries of Wine 0.9.14 for Windows from June 2006, and the page CompilingDLLsUsingMingw.

Wine on Cygwin

Status

Wine now compiles on Cygwin! Mostly.

If you see a compilation failure in dlls/atl, delete dlls/atl/atliface.h and try again.

Work to be done

Attempting compilation will finish without bombing out. However, not everything compiles - not even close.

  • As much as possible should compile (and even work).
  • Check how well the .EXE and .DLL made by Wine on Cygwin work in Windows. If a MinGW-compiled DLL works in Windows, a Cygwin-compiled DLL should.
  • ./configure fails to pick up the presence of a lot of packages it should. This page may have some relevance.

  • Win16 is disabled in Cygwin (severe compilation problems). Enabling that and getting it to compile would be interesting.
  • Get the DirectX 10/11 implementation working well enough to be usable as a lib on Windows XP.

And, of course:

  • Does anyone want to write a program loader that (a) works (b) doesn't interfere with Windows' attempt to do the same?

Installing

Install the following from Cygwin setup.exe:

  • devel/bison
  • devel/ccache (for RegressionTesting)

  • devel/flex
  • devel/gcc
  • devel/gettext-devel
  • devel/gnutls-devel
  • devel/libjpeg-devel
  • devel/liblcms-devel
  • devel/libncurses-devel
  • devel/libpng12-devel
  • devel/make
  • devel/openldap-devel
  • devel/openssl-devel
  • devel/pkg-config
  • graphics/libtiff-devel
  • libs/libtiff-devel
  • libs/libxml2-devel
  • libs/libxslt-devel
  • system/libdbus1-devel
  • X11/libfontconfig-devel
  • X11/libX11-devel

You probably also want these to experiment with tweaks:

  • devel/patch
  • utils/patchutils

Get source from the tarball or git, and go into the directory in the usual manner.

./configure
make

Ideas

  • What's up with Cygwin's header files? Why does Wine check what it does? (Change introduced in 2003.)
  • Parity may help in other respects.

Wine on MinGW

MinGW is not a complete subsystem - it's the GNU tools ported to Windows, to build software that uses them natively. With more or less source patching. There is an optional shell, MSYS, which is derived from Cygwin.

You can compile Wine DLLs for use on Windows using MinGW. This is described on the wiki page CompilingDLLsUsingMingw.

The main problem getting wine to work under MingGW is X11 libs. The donation-paid version of Xming comes with Xlibs, but not the free version. Compiling X11 in MinGW is fraught, as it really stresses what a POSIX implementation can supply.

Status

Current results are not great.

DavidGerard tried:

./configure --without-x --without-freetype runs! Till now you were able to do everything with mingw/msys in Wine(as of Wine-1.1.27), but now there are different problems. On Windows make depend bombs out with:

...
../../../tools/makedep -C. -S../../.. -T../../..  cred.c crypt.c crypt_lmhash.c crypt_md4.c crypt_md5.c crypt_sha.c lsa.c registry.c security.c service.c
make[2]: Leaving directory `/home/fun/wine-1.1.11/dlls/advapi32/tests'
make[2]: Entering directory `/home/fun/wine-1.1.11/dlls/advapi32/tests'
Makefile:442: *** unterminated variable reference.  Stop.
make[2]: Leaving directory `/home/fun/wine-1.1.11/dlls/advapi32/tests'
make[1]: *** [advapi32/tests/__depend__] Error 2
make[1]: Leaving directory `/home/fun/wine-1.1.11/dlls'
make: *** [dlls/__depend__] Error 2

In Wine with mingw/msys make has problems to compile libwine.dll with dllwrap.

libX11

what DavidGerard did on his holidays

--without-x is not very useful. So we need libX11.

Prerequisites

  • libX11 wants pkg-config. This has a circular dependency on glib. The MinGW-recommended way is to install the gtk+-2.0 exe first. Then download pkg-config, copy pkg-config.exe to your MinGW /bin/ and pkg-config.m4 to /usr/local/share/aclocal/ .

  • xcb demands Python. Thankfully the official Windows build (I used 2.5.x) will do just fine. (You can't do interactive Python from the MSYS command line, but it'll run Python programs you give it.) Do:

ln -s /c/Python25/python.exe /usr/local/bin/

  • xcb demands xsltproc. Get libxslt from Igor Zlatković's site. (Read this before you use it for any other purposes.)

  • xcb's libpthread-stubs demands pthreads. Still trying to work around this one. (I shouldn't have to, as xcb is supposed to support MinGW ...) Current attempt:

    • Get the self-extractor from Pthreads Win32. Extract to a temporary directory.

    • Copy the four files with GC in the name from Pre-built.2\lib to MSYS's /lib, copy the headers from Pre-built.2\include to /include.
    • Copy the headers also to the libpthread-stubs build dir.
    • This then fails with "warning: weak declaration of 'pthread_self' not supported", which is an ELF vs PE-COFF problem which should be able to be worked around with Makefile tweaking.

Building

According to this message from July 2005, to build libX11 from source you need to build the following, in order:

  • Xproto from xlibs
  • Xau from xlibs
  • xcb-proto
  • xcb
  • XExtensions from xlibs
  • xtrans from xlibs
  • X11 from xlibs

See CompileXserverManually.

DavidGerard compiled these in order, using ./autogen.sh && make && make install (except as noted, ./configure && make && make install ). Start with something like:

export ACLOCAL="aclocal -I /usr/local/share/aclocal/"

You may then have to beat it around the head a bit. To get libX11 to build, I had to do all of these for various stupid reasons:

mv ltmain.sh ltmain.sh.old
ln -s /mingw/bin/pkg-config.exe /usr/local/bin

Ideas

  • There's a MinGW version of gcc 4, which may get around some odd behaviour.
  • Build X --without-xcb.
  • Use an older X.
  • Just another completely untested thought at this point: what about Japeth's HX extender (especially the GUI extensions: http://www.japheth.de/HX.html#hxgui)

  • Risky thought : what about winent.drv from ARWINSS instead of X

  • There are pre-built libX11 binaries for MinGW: XportMinGW

Wine on Interix

Interix doesn't come with an X server, but it does come with X11 libraries. It doesn't use ELF, however, which will be hard to work around.

Interix runs as a separate NT subsystem to Win32 (which Cygwin and MinGW run in), and has other limitations. See netbsd pkgsrc page for a list.

You'll need 7zip or something to untar the Wine source tarball (.tar.bz2).

This work is much more likely to work in SUA (Vista and up) rather than SFU (XP, 2003) as it implements more common POSIX calls.

These notes are with SFU 3.5 on XPsp3. Reports from SUA on Windows 2003r2, Vista, 2008 or Windows 7 would be of interest.

RoderickColenbrander notes: "Someone recently claimed that he indeed had wine working on Interix on a 32-bit WinXP. Right now he was trying to compile it on a 64-bit Windows but had all sorts of troubles. For instance there is some define for ELF stuff which he had to disable. He didn't succeed in compiling it and I have doubts that he succeeded before but Interix looks the most promosing of the options right now.

Installing/enabling Interix

Windows 2000 / XP

  • Download the installer (217MB).

  • Custom install, make sure you include all the development stuff! (Interix GNU SDK, Interix SDK)
  • Install hotfixes: GCC fixes, memory usage (these include many previous hotfixes)

The included GNU SDK is too cruddy to use for Wine. SUA Community used to have the GNU tools as packages, but the site has shut down. So you'll have to install from source. The included gcc is 3.3, which is good enough.

Do all this in a directory without a space in the name - several of the tools get confused.

Put /usr/local/bin at the front of $PATH so you get your hand-built tools first:

PATH=/usr/local/bin:$PATH;export PATH

Download, compile and install the following (with ./configure && make && make install ), in order:

Freetype 2 compiles OK from source, but ./configure doesn't detect it. So we need --without-freetype .

Vista / Windows 7

  • Control Panel -> Uninstall a Program -> Turn Windows features on or off

  • Tick "Subsystem for UNIX-based Applications", OK
  • Get the SDK and utilities (all programs, including the shell) - 472MB.

  • Custom install, install SDK and GNU SDK.

Installation

CC="ccache gcc" ./configure --without-freetype
make depend
make

Microsoft suggests a configure line like:

CFLAGS="-D_ALL_SOURCE" CXXFLAGS="-D_ALL_SOURCE" ./configure --without-freetype

Status

On SFU 3.5 for Wine 1.2-rc6, make crashes out with:

gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -DWINE_UNICODE_API="" -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wstrict-prototypes -Wwrite-strings -Wpointer-arith  -g -O2  -o config.o ./config.c -DBINDIR='"/usr/local/bin"' -DDLLDIR='"/usr/local/lib/wine"' -DLIB_TO_BINDIR=\"`../../tools/relpath/usr/local/lib /usr/local/bin`\" -DLIB_TO_DLLDIR=\"`../../tools/relpath /usr/local/lib /usr/local/lib/wine`\" -DBIN_TO_DLLDIR=\"`../../tools/relpath /usr/local/bin /usr/local/lib/wine`\" -DBIN_TO_DATADIR=\"`../../tools/relpath /usr/local/bin /usr/local/share/wine`\"
config.c: In function `get_runtime_libdir':
config.c:123: error: `Dl_info' undeclared (first use in this function)
config.c:123: error: (Each undeclared identifier is reported only once
config.c:123: error: for each function it appears in.)
config.c:123: error: parse error before "info"
config.c:126: warning: implicit declaration of function `dladdr'
config.c:126: error: `info' undeclared (first use in this function)
make[1]: *** [config.o] Error 1
make[1]: Leaving directory `/dev/fs/C/wine-1.2-rc6/libs/wine'
make: *** [libs/wine] Error 2

On SUA 6.1 (Win 7) for Wine 1.1.17, make crashes out here:

`makedep' is up to date.
gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wwrite-strings -Wpointer-arith  -D_ALL_SOURCE -o ffs.o ffs.c
In file included from ffs.c:22:
../../include/wine/port.h:280: error: parse error before "sizeof"
../../include/wine/port.h:284: error: parse error before "sizeof"
*** Error code 1

Stop in /dev/fs/C/wine-1.1.17/libs/port.
*** Error code 1

Stop in /dev/fs/C/wine-1.1.17/libs (line 345 of Makefile).
*** Error code 1

Stop in /dev/fs/C/wine-1.1.17 (line 393 of Makefile).

Ideas

Wine on UWIN

Wine on coLinux

  • Wine will probably run properly on this platform without too much pain, and can use the Linux loader.
  • coLinux needs the ability to grab and release physical memory pending on demand.
  • coLinux needs the ability to access Windows subsystem filesystem.
  • However these issues may be easier to fix than porting Wine to the Windows subsystem, and would also benefit other OSS projects.
  • Website

  • coLinux is a subsystem and needs administrator access for installation. This is an issue that cannot be solved as it is the nature of coLinux, and applications using coLinux are unable to run without admin access. On the other hand most Wine users probably have the ability to run installers that require admin access.
  • coLinux is a Win32-only kernel mode driver, and will not work on Win64.

Wine on andLinux

It already works!

  • As of that picture

  • Perfect for simple GUI apps
  • Might not work with 3D
  • andLinux has the same restrictions as coLinux

"The whole concept of "tricking" windows into being useful is just such a deviant thrill." - Thomas Stover on reading this page

"I am torn between 'That is disgusting beyond words' and 'I salute your awesome perversity'. Really." - Eric S. Raymond (maintainer of INTERCAL)


CategoryDistributions

WineOnWindows (last edited 2014-01-26 01:47:33 by JohnCowan)