Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site medstar.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!whuxl!whuxlm!akgua!gatech!medstar!robin
From: ro...@medstar.UUCP (Robin Cutshaw)
Newsgroups: net.unix-wizards,net.micro.pc
Subject: Xenix286 Wonders, Bugs, and Patches...
Message-ID: <168@medstar.UUCP>
Date: Thu, 2-May-85 17:03:22 EDT
Article-I.D.: medstar.168
Posted: Thu May 2 17:03:22 1985
Date-Received: Fri, 3-May-85 23:35:04 EDT
Distribution: net
Organization: Medical Systems Technology and Research, Inc., Atlanta, Ga.
Lines: 250
For the most part I have been very impressed with Xenix286 3.0 for
the AT. It seems to be fairly fast (except for c-compiles) and has greatly
increased the amount of work that I can accomplish. The DOS cross-development
utilities work very well (at least so far).
I have just about completed a device driver for the IBM PC Network
adapter. Anyone interested in beta testing please let me know. I will
also be posting an article on writing device drivers for Xenix.
I have found many wonderful buglets while porting code to Xenix. Many
of these bugs were found while porting news2.10.2 and HACK, both of which now
work wonderfully (with several modifications). Patches mentioned below will
follow shortly. I would be interested in getting any other bugs that you find.
adb:
./W 'abcd' writes 'cdcd'
?M just doesn't work /*/ IBM says this command is not and will not
be supported, it will be removed from the
documentation
size of /dev/mem is short by 1/2K. See related variable in the kernel.
.cshrc/.login :
set ignoreeof in .cshrc should be in .login /* IBM agrees */
malloc :
never returns more than ~32KB (actually 32634) /* IBM says "too bad" */
realloc :
doesn't work in large model programs
cc :
order of args is important (like where you put -M2el)
arrays of exactly 64K bomb the loader with "> 64K array" error, if
you create an array of 64K-1 it will create a 64K array due to even
alignment
no crypt() in libc.a /* IBM says it cannot ship overseas with this */
error recovery is terrible (a missing ")" can bomb every following line)
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).
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 is compiling this routine, therefore any non-zero value
on the stack prior to the exec call will not give the routine a zero
terminator. The si register is on the stack prior to the exec call.
BITFIELDS initialize wrong. Bytes are initialized instead of bits
leading to massive initialization errors down the line. Don't
auto-initialize them.
The -MxTyyyy option is documented wrong. It is a hex value which
defaults to 0xffff (don't use the 0x).
All pointer arithmetic is 16 bits long (including the large model 32 bit
pointers). This can get you into trouble if you were crazy enough to
subtract pointers in differing segments. (ala HACK).
The loader will only give you 4004 usable stack space. You must run
stackuse to see if that will be enough (GASP!) and use the -F option
(which uses a hex value i.e. -F 2000 for 8K) to increase stack space.
This is GROSS!! Your program may bomb in one of several ways if you
don't have enough stack allocated. Stackuse doesn't always work! The
first data segment and stack segment share the same 64K segment, even in
large model programs. Good luck.
The O_NDELAY option to open() may not work in some instances.
make :
make -n doesn't always give you the sequence that make alone will
make will run out of environment space if you have several things set
in yours, especially if you run the c-shell
tar :
one must link /dev/mt1 to /dev/fd0 for tar to work (or your standard
floppy device)
tar doesn't back up empty directories (not sure that it should)
tar uk 1150 won't work properly
restor :
Will not work if your environment is too large, may not work anyway
function keys :
These are user defined (GASP!!). It would have been much better for
application programmers if they had just given them a standard escape
sequence and been done with it. One cannot read their values back to
see what they are currently set to do, so if you have multiple processes
changing them you can get into lots of trouble. The SETKEY command does
not allow the standard "^*" escapes so one cannot insert control
characters with this command, use Esc Q x "sss". All fkey defs are
erased when you log off. I will be posting a patch to read the fkeys
and a patch to permanently set them to some "known" string.
cursor keys/setkey :
Only Home, left, right, up, and down, are recognized by the kernel.
There is a table of strings to pass on to ttin for each key and the
other cursor keys are set to NULL. I have a patch for this and will
post shortly.
stackuse :
Will barf if more than a few programs to scan.
Uses a .cu file for internal use, but this will overwrite the source
file if only the .c part is used due to the filename length (BARF!)
vi :
Cannot edit large files. One must patch the stacksize in the x.out
header from 0x8000 to 0x5000. Will post patch shortly.
csh :
No pushd-popd
Doesn't notify you when a background task has finished
#!/bin/sh doesn't work
No unsetenv so you are stuck with it
sh :
#!/bin/sh will execute csh
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.
stty/gtty :
If one passes the sgttyb struct to stty that came from gtty, the
echoe bit will be cleared.
dmesg :
No man entry.
/usr/adm/msgbuf must be present before the - option works as seen in
crontab
cron :
Even if /etc/default/cron parameter CRONLOG is set to YES the file
/usr/lib/cronlog must exist to get the log (it doesn't create it)
uucp :
A bug in S3 uucp make uustat unusable if /usr/lib/uucp and
/usr/spool/uucp are not on the same file system due to us_open trying
to link rstat.pid in /usr/spool/uucp to R_stat in /usr/lib/uucp.
This was fixed in S5.
The basic operations guide gives an incorrect example of a dialin/dialout
script for crontab. A corrected one follows (/usr/lib/uucp/uuhourly) :
#
/bin/disable /dev/tty00
if ($status == 0) then
sleep 20
/usr/lib/uucp/uucico -r1
/bin/enable /dev/tty00
endif
EGA support :
Xenix only supports compatability mode on the EGA. A patch has already
been posted to the net to fix this (ret for initCRTC in /xenix).
Does not support monochrome monitor on EGA.
DOC :
Many, many, many, misprints! Lots of spaces between switches and arguments
(i.e. -M2eT xxxx where it should be -M2eTxxxx). In the device driver
section replace all cent signs with [ and most | signs with ].
Patching the kernel :
Permanent -
adb -w /xenix -
Online -
adb -w /xenix /dev/kmem
* $x
* /m 18 0 e400
* ...your patches...
DISKINFO :
If you use a drive other than the standard type 2 you will have to patch
the kernel. It seems that the diskinfo table which corresponds with the
BIOS table of 15 is incorrect. Also, /boot will not work if you have
more than 4 heads. I will post a patch to this shortly.
/etc/hdinit will work for type 2 but not well for others.
Shared data :
The function sdget() must include the size param at all times and the
mode param one the first call. This is documented wrong in the manual.
Color :
Color works well with the ansi escape sequences as described in the DOS
manual. No multiple arguments are allowed though (i.e. Esc[#;#m must
be Esc[#mEsc[#m).
from .cshrc :
if ($TERM == ansi)
set prompt="Esc[36m# Esc[0mEsc[37m" # set blue prompt
else
set prompt="# "
endif
note : replace Esc with the escape character
Questions, comments, bugs to me...
--
----
Robin Cutshaw
Director of Systems Research, MedSTAR, Inc.
..{akgua,gatech,gacsr}!medstar!robin
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: g...@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
> 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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards,net.micro.pc
Subject: Re: Xenix286 Wonders, Bugs, and Patches...
Message-ID: <5574@utzoo.UUCP>
Date: Wed, 8-May-85 13:44:47 EDT
Article-I.D.: utzoo.5574
Posted: Wed May 8 13:44:47 1985
Date-Received: Wed, 8-May-85 13:44:47 EDT
References: <168@medstar.UUCP> <2158@sun.uucp>, <1143@cbosgd.UUCP>
Organization: U of Toronto Zoology
Lines: 7
> I wonder what the /usr/group standard and the System V standard recently
> published say? [about the last argument to execl]
Both get it right: the last argument is "(char *)0", not just "0".
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!uwvax!harvard!talcott!panda!genrad!
decvax!decwrl!Glacier!mips!mash
From: m...@mips.UUCP (John Mashey)
Newsgroups: net.unix-wizards,net.micro.pc
Subject: Re: Xenix286 Wonders, Bugs, and Patches...
Message-ID: <131@mips.UUCP>
Date: Wed, 8-May-85 13:51:01 EDT
Article-I.D.: mips.131
Posted: Wed May 8 13:51:01 1985
Date-Received: Sat, 11-May-85 08:19:51 EDT
References: <168@medstar.UUCP> <2158@sun.uucp> <1143@cbosgd.UUCP>
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 36
> In article <2...@sun.uucp> g...@sun.uucp (Guy Harris) writes:
> >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
....
Mark Horton <1...@cbosgd.UUCP> writes:
>
> 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
> ...
Not quite: more accurately (<bad words> upon the numbering):
PWB/UNIX 1.0 was a Version 6-based system, as was 1.1 & 1.2; only 1.0
was released outside, as I recall [which was too bad: 1.2 was a really
clean, well-tuned V6].
UNIX/TS 1.0 [my manual says Nov 78] was basically V7 + few kernel changes
derived from PWB + some USG Generic 3 stuff. It's goal was to get at least the
time-sharing kernel interface standard. It didn't have SCCS & other PWB
major user-level subsystems, although little things crept in.
PWB/UNIX 2.0 [June 1979] was UNIX/TS 1.0 + the rest of the PWB stuff.
UNIX 3.0 [June 1980] was System III. Note there was no UNIX 2.0, whose
number was taken by the last PWB release. Most of PWB/UNIX 2.0 was included.
This is where ioctl & echoe appear.
--
-john mashey
UUCP: {decvax,ucbvax,ihnp4}!decwrl!glacier!mips!mash
ARPA: mips!m...@SU-Glacier.ARPA
DDD: 415-960-1200
USPS: MIPS, 1330 Charleston Rd, Mtn View, CA 94043