Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!bellcore!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix-wizards,net.micro.pc
Subject: Re: Xenix286 Wonders, Bugs, and Patches...
Message-ID: <2158@sun.uucp>
Date: Sat, 4-May-85 05:19:34 EDT
Article-I.D.: sun.2158
Posted: Sat May  4 05:19:34 1985
Date-Received: Mon, 6-May-85 00:55:05 EDT
References: <168@medstar.UUCP>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 75
Xref: watmath net.unix-wizards:13074 net.micro.pc:3870

> 	no crypt() in libc.a	/* IBM says it cannot ship overseas with this

AT&T also says so.  The problem is that the gov't has some sort of embargo
on exporting "encryption technology", and instead of AT&T trying to get
an exemption for the code in UNIX they just decided to say "no, you can't
export any encryption code" and introduced "International System V".  Feh.

> 	uname() returns NULL for nodename instead of the nodename in
> 	/etc/systemid, you can patch the kernel with your nodename at
>	_utsname+8 (should not exceed 7 characters).

Every other System(III|V) I've seen supported 9 characters (or 8 plus
a '\0' at the end) for the names in the "utsname" structure.  Don't know
why Microsoft changed it...

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

> 	tar doesn't back up empty directories (not sure that it should)

Standard "tar" doesn't dump directories at all; the only reason non-empty
directories appear is that "tar" creates needed directories when extracting
files.  The 4.xBSD "tar" writes entries for directories as well as files,
which has the side effect that empty directories are dumped.

> csh :
> 
> 	#!/bin/sh doesn't work
> 
> sh :
> 
> 	#!/bin/sh will execute csh

"#!" is a kernel feature, and is only in 4.xBSD and a few other systems
(Masscomp?).  Microsoft didn't pick it up.

> strings :
> 
> 	The -o option for offsets doesn't work because they compiled the
> 	Berkeley version with "%D" instead of "%ld".  This compiler doesn't
> 	recognize D as a valid format for printf.

"printf" was changed in System III so that %[DOX] no longer are equivalent
to %l[dox].  The latter is preferable, both because System III/V don't
support the former and because %D in programs gets turned into a date by
SCCS.  Nobody should be using %D, %O, or %X anymore; %ld, %lo, and %lx work
just as well and will also work in System III/V.

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

	Guy Harris