Mike MacDonald mmacdona@tsi.gte.com
Tue Nov 9 07:41:00 GMT 1999

Ok, you have to forgive me, I'm new to alot of this stuff.  What you seem to
be saying is that the driver is there to provide the same interface that X
expects.  I need, I think, to look at the XFree code (which I haven't yet)
to see what you are talking about.   I'm assuming that a straight library
won't give X access to the ports it needs without rewriting alot of the asm

How do the ASM functions access the ports?  I guess thats what I need to
find out.  if they just do in and out and the port number - then the driver
has to make sure those port numbers are available to X in general?  If thats
the case, then how did you do that?

I'm not sure, but switching to a full screen mode in DirectX might give
direct access to the ports from X..  If thats the case, then it might just
be a matter of changing modes, and depending on DX for the direct video card

Other than that, I think I see where you are coming from.  I need to find
out what the quickest way to access an IO port in Winnt/Win98..  Since
DirectX was designed to be able to access the video card directly, and
quickly, I'm hoping that it will provide the necessary connections.

-----Original Message-----
From: Holger Veit [ mailto:Holger.Veit@gmd.de ]
Sent: Tuesday, November 09, 1999 2:49 AM
To: Mike MacDonald
Subject: Re: XF86SUP.SYS

On Mon, Nov 08, 1999 at 07:10:59PM -0500,
	Mike MacDonald wrote:
> Hi, I'm trying to port your driver to Win98/NT.  After looking at it
> superficially, I can't see why we can't just implement this as a library -
> since WinXX doesn't have the same issues with Ring0 as OS/2 seems to.  I'm
> just wondering if there are other reasons for making it a driver.  If
> persistance is necessary for ptys or something, we can just provide a
> service under Windows..  I think though that even that can be handled in a
> library..

There are specific reasons why this is a driver in OS/2. OS/2 has a
to do I/O in a special ring2 mode, i.e. it is possible to declare a
ring2 library with function calls that allow access to I/O ports. I believe
NT has a similar facility. The problem is, that this results in a callgate
transition, not just a simple far call for any inb/outb instruction. This
slows down the call by up to two magnitudes. Speed for I/O instructions is
essential particularly for accelerated video cards; you'll likely leave the
acceleration pipeline of the video card empty with too slow access thus
significant performance loss. A less important reason is that I was
to rewrite all the assembler code in XFree86 that did I/O by assembler
The PTY stuff has, in conjunction with EMX, another important reason to make
it a character driver: some utilities behave different when their stdin or
stdout is connected to a pipe vs. a character device, see the 'ls' output
as a simple example (multi column in xterm, vs single column in 'ls |
There is too much code already existing that relies on that. It would have
trivial to implement PTYs in xterm with an OS/2 pipe, but this would have
real differences in behaviour.

If Microsoft is ever going to produce something that does not suck,
it is very likely a vacuum cleaner.

More information about the Cygwin-xfree mailing list