Win32 version of XFree86

[Rich Thomson]

Hi,

There isn't any need to cc: me on messages regarding a port of Xfree86
to Windows.  In fact, I've unsubscribed from all xfree86 mailing
lists.

My interest is in a DirectX based server, not a port of Xfree86.  I
just don't think a port of xfree86 is the best path to a DirectX X
server.  I think you will get a better server by starting with the
X11R6.4 sample server code and starting with a very simple X server hw
layer that just pushes spans to the DirectDraw code.

The X server is already plenty portable enough on its own for things
like the necessary O/S services.  Everything in the core X server code
is written very portably.  You may need to adjust the imake environment
to suit newer compiler switches and so-on, but you should not need to
make any changes to the X server core code.  The X library code has
already been built on Win32, so some Win32 environment support is
already present in X.  I believe they punted on xterm because of its
pty usage, but it is a special case.  Perhaps you could get xterm
compiled with gcc/cygwin.  At any rate, I'm more interested in a server
before xterm.

The difficulty in a Win32 non-DirectX X server in the past has had to
do with the way resources are shared under X and under Windows.  The
two are not very compatible when it comes to things like colormap
management and focus management and so-on.  Trying to make top-level X
client windows look like Win32 app client windows is annoying and
tedious.

DirectX lets you do away with GDI and take over the screen, which is
exactly what an X server wants to do when it starts.  No hw-specific
drivers are needed because you rely on DirectDraw to provide the device
abstraction.  The X sample server is coded to handle memory-mapped
frame buffers quite efficiently all in software.  From a basic working
server you begin optimizing higher-level requests from there.

That is the X server I'm interested in making.  Since a DX-based server
wouldn't need any of xfree86/hw code, all that code just goes away.
But wait, you just threw out 90% of the xfree86 server effort.  Is
there any reason to keep the remaining 10%?  The remaining 10% of code
consists of startup/shutdown code, font code, input device code, and
the OS layer code.  All of this code in xfree86 is from a unix
viewpoint, so it must be changed anyway for a Win32 DirectX based X
server.

The startup/shutdown code can't be used from xfree86 because device
management is totally different under Windows.

The X server only requires a few routines for supporting the basic
keyboard and mouse events and a few more for extension devices (like a
gamepad/joystick).  We can use Windows event mechanism, or use
DirectInput for device input.  Either way, we can't use the xfree86
code.

The font code is probably stock X server font code, which means it
can't take advantage of Windows fonts.  Eventually you'd like to be
able to take advantage of Windows installed fonts for a DirectX based
server, so you'd need to adjust the font code.

The OS layer code is easy to supply for native Win32.  For several of
the functions, you can use the unix equivalent just fine on Win32
(things like opening files, opening socket connections, etc).

So, in the end, you can't hardly use any of the xfree86 code in a very
useful way for a native Win32 directX-based X server.  The part of the
code that you can reuse comes from the core sample server, not from
xfree86.

If you tried to use the xfree86 code, you have to deal with the way it
wants to talk directly to all the different hardware out there.  The
core X server itself isn't coded this way, the xfree86 portions of it
are.  The xfree86 portions include assembly code, unix-oriented I/O
code, unix-oriented device management code.  For a DirectX server these
are replaced with DirectDraw and Win32.

So in the end I came to the conclusion that trying to port Xfree86
would be more work than just porting the core sample server itself.
This is usually not the case, because normally you don't have a
HW-independent abstraction beneath you when porting the X server.
Usually you have to do what Xfree86 has done and support the different
hardware directly.  Its tedious, cumbersome and *lots* of code for the
amount of hardware in the PC world today.

But with a DirectX PC, MS and the hardware vendor have already provided
the abstraction that takes away the complexity of the hardware.

You are, of course, free to pursue your own direction.  However, I am
more interested in making the X server I've described in this message.

-- Rich