RE: XF86SUP.SYS

[Mike MacDonald <mmacdona at tsi dot gte dot com>]

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
functions.

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
access.

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
mechanism
to do I/O in a special ring2 mode, i.e. it is possible to declare a
privileged
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
causing
significant performance loss. A less important reason is that I was
reluctant
to rewrite all the assembler code in XFree86 that did I/O by assembler
inlines.
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 |
more').
There is too much code already existing that relies on that. It would have
been
trivial to implement PTYs in xterm with an OS/2 pipe, but this would have
caused
real differences in behaviour.

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