[comp.windows.x] x-window on pc

simnet@ssc-vax.UUCP (Mark R Poulson) (10/31/89)

I'm looking for ways to develop X-Windows application software and run it on 
an IBM PC or compatible (possibly under the Xenix OS).  My final product 
should also need to be portable e.g. to a SUN.  Any idea or comment will be
greatly appreciated.

A. Hsu

madd@world.std.com (jim frost) (11/12/89)

simnet@ssc-vax.UUCP (Mark R Poulson) writes:
>I'm looking for ways to develop X-Windows application software and run it on 
>an IBM PC or compatible (possibly under the Xenix OS).  My final product 
>should also need to be portable e.g. to a SUN.  Any idea or comment will be
>greatly appreciated.

Well-written X applications are highly portable, so that shouldn't be
a major problem.  If you make use of UNIX-flavor-dependent functions,
such as tty control, it's a little harder.  This kind of thing is
generally unnecessary under X.

If you want to do this, I recommend using Interactive Systems Corp's
386/ix instead of Xenix.  They have the best 386 X windows I've ever
seen, period.  ESIX's X had poor performance relative to Interactive
even though they were running on exactly the same hardware.  Xenix,
last I heard, was still R2.  Xenix also uses the flaky Microsoft
compiler.  Pcc isn't great but it's fairly reliable.

If you want to write X applications on a 8086 or 80286 machine, good
luck.  There are fairly useful servers that run on those machines but
no good systems to run servers and clients.

jim frost
software tool & die     "The World" Public Access Unix for the '90s
madd@std.com            +1 617-739-WRLD  24hrs {3,12,24}00bps

chasm@attctc.Dallas.TX.US (Charles Marslett) (11/14/89)

In article <1989Nov11.175220.25696@world.std.com>, madd@world.std.com (jim frost) writes:
> simnet@ssc-vax.UUCP (Mark R Poulson) writes:
> >I'm looking for ways to develop X-Windows application software and run it on 
> >an IBM PC or compatible (possibly under the Xenix OS).  My final product 
> >should also need to be portable e.g. to a SUN.  Any idea or comment will be
> >greatly appreciated.
> 
> Well-written X applications are highly portable, so that shouldn't be
> a major problem.  If you make use of UNIX-flavor-dependent functions,
> such as tty control, it's a little harder.  This kind of thing is
> generally unnecessary under X.
> 
> If you want to do this, I recommend using Interactive Systems Corp's
> 386/ix instead of Xenix.  They have the best 386 X windows I've ever
> seen, period.  ESIX's X had poor performance relative to Interactive
> even though they were running on exactly the same hardware.  Xenix,
> last I heard, was still R2.  Xenix also uses the flaky Microsoft
> compiler.  Pcc isn't great but it's fairly reliable.

As a corollary, I have been trying to get support from any of the Unix
vendors for 256-color X-windows drivers.  None offered to provide them,
but Interactive has been working diligently, and has been testing my code
for me against their applications, so I am very pleased with their
support for X11.

On the other hand, I have tried several times to discuss what I have to do
to support X11 in 8-plane mode, and I have yet to talk to the same person
twice at SCO (and I haven't really tried to talk to anyone at Everex yet).

In general, I think Interactive is much more committed to Xwindows than
the other vendors.

[And our 256-color 800x600 and 1024x768 drivers will work there, too;^)]

> jim frost
> software tool & die     "The World" Public Access Unix for the '90s
> madd@std.com            +1 617-739-WRLD  24hrs {3,12,24}00bps

===============================================================================
"Those who would sacrifice **  Charles Marslett
liberty for security,      **  STB Systems, Inc. <-- apply all std. disclaimers
deserve neither."          **  Wordmark Systems  <-- that's just me
  -- Benjamin Franklin     **  chasm\@attctc.dallas.tx.us
-------------------------------------------------------------------------------

madd@world.std.com (jim frost) (11/15/89)

chasm@attctc.Dallas.TX.US (Charles Marslett) writes:
>In article <1989Nov11.175220.25696@world.std.com>, madd@world.std.com (jim frost) writes:
>As a corollary, I have been trying to get support from any of the Unix
>vendors for 256-color X-windows drivers.  None offered to provide them,
>but Interactive has been working diligently,

The last time I spoke with the ISC technical people, they stated that
they didn't support 8-bit color because it was too slow.  Having used
a Sun386i with 8-bit color, let me tell you that they're probably
right.  A lot of optimization needs to be done to make it acceptable.
ISC seems to have done fairly well so far, though.

>On the other hand, I have tried several times to discuss what I have to do
>to support X11 in 8-plane mode,

You shouldn't have to do anything special; you'll just have a pallette
of 256 colors to work with instead of 16 unless you're doing something
like colormap-based double-buffering.

If you need fairly well-written color code, I have a bunch of it
laying around; one such program is xloadimage, an image display
utility, which was recently posted on comp.sources.x if you want to
grab it.  It has a LOT of color support for n-bit displays.

Happy hacking,

jim frost
software tool & die     "The World" Public Access Unix for the '90s
madd@std.com            +1 617-739-WRLD  24hrs {3,12,24}00bps

chasm@attctc.Dallas.TX.US (Charles Marslett) (11/21/89)

In article <1989Nov15.003835.4889@world.std.com>, madd@world.std.com (jim frost) writes:
> chasm@attctc.Dallas.TX.US (Charles Marslett) writes:
> >In article <1989Nov11.175220.25696@world.std.com>, madd@world.std.com (jim frost) writes:
> >As a corollary, I have been trying to get support from any of the Unix
> >vendors for 256-color X-windows drivers.  None offered to provide them,
> >but Interactive has been working diligently,
> 
> The last time I spoke with the ISC technical people, they stated that
> they didn't support 8-bit color because it was too slow.  Having used
> a Sun386i with 8-bit color, let me tell you that they're probably
> right.  A lot of optimization needs to be done to make it acceptable.
> ISC seems to have done fairly well so far, though.

The 256 color server I am currently working on is only a week from being 100%
C code.  It runs considerably faster than the original 16-color server for
the VGA shipped with 386/ix in September.  [It also runs a bit slower than
the current "soon to be released" 16-color server that it should be compared
against.]  The screen-to-screen copy (bitblt) runs almost twice
as fast as the new 16-bit server though (character output is about a third
as fast, to balance things out).

I think on average the VGA 256-color X11 server should run "almost" as fast
as the 16-color server.  And the individuals at ISC who have disagreed from
the first simply do not "know" the VGA and its architecture [I DO!].  Though
the 16-color mode often has twice the bandwidth of 256-color modes, and the
256-color modes have to shove twice the bits around, they involve lots of I/O
(and in protected mode 286, and especially 386, code that slows everything
down).

I still have to stand by my statement that they are helping me a lot more
than the competition (unnamed ;^).  Even if they, generally, don't believe
it can be done!

> >On the other hand, I have tried several times to discuss what I have to do
> >to support X11 in 8-plane mode,
> 
> You shouldn't have to do anything special; you'll just have a pallette
> of 256 colors to work with instead of 16 unless you're doing something
> like colormap-based double-buffering.

No . . ., try looking at the way the video memory is organized in the VGA 16-
color modes, and how it is organized in the 256-color modes.  An efficient
server for one set of modes is not likely to be well organized for the other.
Specifically, one is a heavy user of I/O instructions, the other cannot
usefully take advantage of the VGA's internal latches.  ETC.

> Happy hacking,
> 
> jim frost
> software tool & die     "The World" Public Access Unix for the '90s
> madd@std.com            +1 617-739-WRLD  24hrs {3,12,24}00bps

Charles Marslett [a bad boy, at interactive now, since they told me to
                  shut up, and <since I don't work for them, and since
                  I like to shoot off my mouth> I ain't]
chasm@attctc.Dallas.TX.US (or some other reasonable facsimile)

madd@world.std.com (jim frost) (11/22/89)

chasm@attctc.Dallas.TX.US (Charles Marslett) writes:
>> >On the other hand, I have tried several times to discuss what I have to do
>> >to support X11 in 8-plane mode,
>> 
>> You shouldn't have to do anything special; you'll just have a pallette
>> of 256 colors to work with instead of 16 unless you're doing something
>> like colormap-based double-buffering.

>No . . ., try looking at the way the video memory is organized in the VGA 16-
>color modes, and how it is organized in the 256-color modes.

I thought he was asking about client-side, not server side.  If this
is not the case, I apologize.

jim frost
madd@std.com