RE: Win32 version of XFree86

["Suhaib M. Siddiqi" <ssiddiqi@inspirepharm.com>]

> > Could you first look into various OS-specific codes in the
> > Xserver/hw/xfree86/os-support?  That is where most of the work we
> > need to do.  That is provide those functionalities for Win32 API.
>
> Ok. So it sounds like it is all compiling, but a lot of the framework
> code is not necessarily there? What about event handling? Is any of
> that done yet?
>

That code compiles too from XFree86.  Most of stuff for event handeling
in xfree86 is supported by Cygwin UNIX emulation layer.

> > X11R6.4 is, but not the Xfree86 which is being added by Xfree86 Org.
>
> I have not checked specifically, but how much assembler code is there
> in XFree86 that is outside of chipset specific drivers?

It is in various sub-directories in Xserver/hw/xfree86.
The VGA/SVGA chipset code you want to hook to DirectX has a lot of
assembly code in it.  Look at Xserver/hw/xfree86/vga's directories.

> Sure, but the actual DirectX rendering code would be done as a
> chipset driver within the SVGA driver framework. That is the quickest
> and easiest way to get something going (and what I am familiar with
> ;-).

If you add your code into hw/xfree86/os-support/win32 it would use the
SVGA chipset code from hw/xfree86/svga2, and hw/xfree86/svga256 etc.
Your could should compile as a static library which could be linked
to X-server excutables.

> Well XFree86 also compiles and runs just fine on OS/2, but I am not
> sure what compiler they use. I was under the impression that either
> Watcom C++ or IBM VisualAge C++ was used to compile the OS/2 version,
> rather than a GNU C variant. However I may be wrong (since emx for
> OS/2 is the GCC for that OS).

They used EMX, that is GCC 2.8.1 and GNU gas assembler.  Xfree86/Os2 port
is a model for porting Xfree86 to Win32.  Holger wrote his own devices
drivers
which allow direct access to i/o ports and maping physical memory to
user area, because OS/2 DDK does not offer these features.  For Win32
we could take DDK or DirectX to access i/o and map, unmap physical memory to
user area???

> > cfb, mfb and dix etc is not a problem.  That is pure C code and compiles
> > perfect with GCC.
>
> Ok. So where does the bulk of the assembler code in XFree86 come from
> then? If it is not in the above, then it must really be just chipset
> driver specifics right? And we don't need those...

It is almost in every subdirectory inside Xserver/hw/xfree86/.
I prefer doing a direct port of Xfree86 to Win32, as Holger
did for OS/2. Throwing away the hw/xfree86 means the X-server
would not be an Xfree86 port, rather X11R6.x classical X.

> Sure, but even GCC 2.9.5 does not compare to the latest commercial
> compilers from Microsoft, Intel and MetroWerks.


I disagree, particularly with MSVC.  MSVC is very buggy.
After M$ released MSVC 6.0, a month after they released a major
services pack 1.0 to address some serious bugs. Since then
3 service packs had been released and 4th one is on its way.
For porting Unices C codes I had better experience with GCC
and EGCS.
I had some C sources which compiled with Absoft Pro without
problems, and MSVC gave a heck of the problems of fixing the code
so MSVC can compile it.  MSVC does do a good optimization job.

Suhaib
>
> Regards,
>
>
> +---------------------------------------------------------------+
> |   SciTech Software - Building Truly Plug'n'Play Software!     |
> +---------------------------------------------------------------+
> | Kendall Bennett          | Email: KendallB@scitechsoft.com    |
> | Director of Engineering  | Phone: (530) 894 8400              |
> | SciTech Software, Inc.   | Fax  : (530) 894 9069              |
> | 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
> | Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
> +---------------------------------------------------------------+
>