Xenix286 Wonders, Bugs, and Patches...

[Mark Horton]

In article <2158 at sun.uucp> guy at sun.uucp (Guy Harris) writes:
>
>> 	exec() doesn't always work with the large model due to NULL being
>>	placed at the end of the arg list instead of (char *)NULL.  This is a
>> 	programmer problem more than a bug.
>> 
>> 	system() doesn't work in the large model if the si register is
>>	non-zero.  This is due to the exec() error above.  They used NULL
>>	instead of (char *) NULL...
>
>The former is not at all a bug.  *Good* programmers know to cast null
>pointers properly.  Other programmers write code that breaks on all the
>machines out there with 16-bit "int"s and > 16-bit pointers...

Sorry, Guy, I wish it were that simple.  Get out your Unix Programmer's
Manual and look up EXECL(3) (or EXEC(2) on System III/V).  You'll notice
that the DOCUMENTED FORM of the execl call says to pass a zero.   Not
a (char *) 0.  Just a plain old 0.  This worked fine on the PDP-11 and
the VAX, but just in the last few years people have discovered that this
single property of UNIX won't work on a machine with pointers that are
bigger than integers.  This includes some 68K implementations (although
most, including Sun, provide 32 bit integers, presumably this is one reason
why) and anything using the large model on an 8086 family machine.

Of course, the fix is easy, just cast the 0 to (char *), but there is a
lot of code out there that doesn't do this.  Also, if you make the cast,
you have to worry about what happens if your code is run on a machine with
big integers and small pointers that didn't change the interface!

I wonder what the /usr/group standard and the System V standard recently
published say?

>> stty/gtty :
>> 
>> 	If one passes the sgttyb struct to stty that came from gtty, the
>> 	echoe bit will be cleared.
>
>By your mention of "echoe", I presume Xenix 286 is System III or V
>compatible.  If so, you should *NOT* be using "stty" or "gtty"!  They are
>implemented only as, to quote the comment in the code, a "compatibility
>aide"(sic).  They are backwards compatible NOT with V7, but with UNIX/TS
>1.0.  UNIX/TS 1.0 didn't support "echoe" (i.e., CRT rubout), but then
>neither did V7; as such, AT&T decided to have "stty" clear the "echoe" bit
>(rather than leaving it alone).  V7 terminal "ioctl"s will NOT work under
>System III/V's tty driver, so programs written for V7 which use "stty" or
>"gtty" have to be rewritten; programs written for UNIX/TS 1.0 should be
>rewritten so that, among other things, they preserve the setting of the
>ECHOE bit.

You mean UNIX/TS 2.0; 1.0 was released to the public as PWB 1.0.  My
impression of Xenix was that they had enhanced the stty emulation to
the point where it handled more than just what 2.0 did - that CBREAK
was now supported and ECHOE got left alone.  (They didn't add support
for TANDEM, but that's pretty obscure.)  You can argue that you should
not use stty on a System III derivative such as Xenix, but you'll find
that lots of pieces shipped with Xenix, like vi and curses, use it.

It is possible that Xenix 286 has less support for the V7 tty driver
than Xenix 3.0 does; I think I would have noticed if my echoe bit got
cleared every time I went into vi or ran a program that uses curses.
However, not having the source to Xenix, I can't be sure.