This is almost possible with the upstream sources. These are notes about what the remaining difficulties we need to address.
While the majority of X.Org modules are portable to MinGW-w64, some aren't or don't make sense to port. (See [1] for a list)
I've made an effort to upstream the minor build fix patches I've accumulated over the past couple of years. This should be done now.
Normally, the X server finds the files it needs using absolute paths configured at build time.
This isn't going to work for an installable Windows executable, so various paths (logfile, fonts, xkbcomp) are adjusted at run-time, usually to place things relative to the executable.
This is fairly well isolated to the DDX, except for a couple of issues:
- dix/registry.c: Needs to be modified to find protocol.txt in relocated root.
There doesn't seem to be any good reason why this file is read at runtime at all. So the upstreamable change would be to read it at build time and convert it to some static data.
- xkbcomp:
This needs to look in the right place both when run by the xserver, and when run standalone. So this needs adjustment as well. (See my notebook 27-Oct-2011)
Patches exist by Ryan Pavlik for some of this work.
Currently XWin doesn't build with the -Werror=implicit-function-declaration, which is included in the default X.Org flags (due to issues with including both libX11 and server headers in the same file), so it's necessary to use -Wno-error=implicit-function-declaration.
Probably the best solution to this problem is convert these pieces of X client code use xcb, which doesn't suffer from these namespacing issues. I have some patches to do that, but they are not upstream yet.
Because they are stdcall, the presence of getaddrinfo() and freeaddrinfo() is not correctly detected by autoconf, so explicit configuration to use ipv6 would be needed if it is wanted.
It seems it's possibly then necessary to include ws2tcpip.h to provide various IPv6 specific defines, which should possibly be done by XWindows.h or Xwinsock.h. (Xwinsock.h isn't widely used, but perhaps should be as there can be constraints on the ordering of including winsock2.h and windows.h)
pthread-stubs is supposed to provides weak aliases for pthread functions, so libraries that rely on pthreads-stubs use pthreads optionally.
This cleverness doesn't work for PE executables.
Need to check that something sensible is happening.
See [2]. LOL.
All the above assumes we are building for a 32-bit target (ILP32 data model)
The X code base has only been built for ILP32 and LP64 data model targets, not the LLP64 data model used by Windows.
I don't know if there are any issues this causes in the X server itself, but e.g. libXt makes extensive use of the assumption that a pointer will fit in a long.
Both VcXsrv and Xming have 64-bit builds, so there should be patches to address this issue.
Mesa is needed to provide GLX OpenGL, and is a whole other complicated beast, so I haven't looked at it at all. People do build it with MinGW and MSVC, so it should be possible.
[1] http://cgit.freedesktop.org/~jturney/jhbuild-config/tree/jhbuildrc.include#n50
[2] http://lists.freedesktop.org/archives/xcb/2011-April/006966.html