caf@omen.UUCP (Chuck Forsberg WA7KGX) (07/01/85)
I'm posting this list of bugs in PC-AT Xenix in the hope that fixes to
some of them might be forthcoming. Except for a few recently discovered
bugs, these bugs have been reported to both IBM and Microsoft repeatedly
since December 1984.
------------
'''Process with mm macros
.nr Ej 0
.de DF
.B
DEFICIENCY:
.R
..
.de BG
.B
BUG:
.R
..
.TL
.AU "Chuck Forsberg" CAF
.AF "Omen Technology Inc"
.MT 4
.sp 4
.ce 3
.B
PC-AT Xenix\(Tm 1.00
User Impressions
.sp 3
.R
.AS
PC-AT Xenix 1.00 is an adaptation of V7 Unix\(Tm
evolving to SYSTEM III and henceforth to SYSTEM V.
Many of the popular Berkeley programs are provided,
including the PDP-11 subset of vi.
Xenix provides some useful system calls not included
in standard Unix.
There are too many missing or broken functions to be able
to call it either V7 or SYS III.
PC-AT Xenix 1.00 is a fair vehicle for developing
small and middle model (data < 64k)
C programs to run under DOS provided you can get your hands on
the macro assembler.
A DOS emulator is sorely needed.
The thought of Unix running on a personal computer with graphics\*F
.FS
As shown on the IBM advertising flyer (6137216 9/84) describing Xenix
.FE
and user responsiveness associated with DOS applications,
and a 4 gigabyte virtual address space\*F,
.FS
Ibid, also IBM PC-AT Technical Reference Manual
.FE
raises heady expectations.
A rude awakening comes as one discovers how many features one has taken for
granted on the PC are locked out of PC-AT Xenix.
Reading that other Unix based workstations support most of these same features
and seeing them demonstrated on the AT&T 7300
don\'t add to the joy.
As a Unix\(Tm workstation, PC-AT Xenix is primitive,
lacking graphics, windows, job control, and the ability to
compile and run the larger Unix applications.
The 80286 segmented memory design precludes successful
large memory
programs in Xenix\'s present state.
Microsoft has yet to
unlock the 80286\'s 4 gigabyte virtual memory capability.
Xenix needs a huge model compiler to exploit
the "32 bit programs"
that constitute the most powerful software being developed for Unix systems.
PC-AT Xenix will make a good workstation if Microsoft is able to "finish"
it before segmented memory processors such as the 80286 become obsolete.
In a speech at the 1985 Dallas Unicom, Microsoft\'s Bill Gates suggested that
an installed base of a few hundred thousand binary compatible Xenix systems
would be necessary for applications to "fly", and that such a penetration
would take place within a few years.
It is my opinion that this will not happen until Xenix gets
graphics, windowing, and objects larger than 64k, allowing it to compete
with other workstation operating systems such as Sun, HP Integral,
AT&T 7300,
and the SYSTEM V/Blit.
Forcing each developer to write device drivers for the keyboard and CRT
to replace the incomplete ones supplied with Xenix will forever postpone
this penetration.
.AE
.H 1 "Strong Points"
Except as noted, the system is reasonably robust and does not crash often.
Some of the random crashes
may be caused by noise coupled through a modem board.
Replacing the modem board with an external modem has (apparently)
eliminated the random crashes.
To date, none of the crashes have caused serious disruption of the
file system, and the normal cleanup procedure has always put things
back in order.
I might say the Xenix filesystem is as robust as DOS, but then this
system has never crashed during periods of intense filesystem activity.\*F
.FS
Given the unsatisfactory disk backup provisions supplied,
I have
.B no
plans to test Xenix's filesystem integrity by crashing the system
during heavy filesystem activity.
.FE
Xenix contains a number of useful extensions to Unix, both
system calls and commands.
The C compiler produces excellent small and middle model code, significantly
tighter than any other 8086 compiler seen to date.
For example, a modified Byte Benchmark (siev.c) compiles to 113 bytes,
compared to 126 bytes (Mark Williams C) and 135 bytes (Lattice C).
Alas, the large model still still (5-85) doesn't work in any reasonable way.
The compiler produces warning messages about dubious pointer operations.
Error recovery is unforgivable.
A misspelling of "static" results in screenfulls of spurious
syntax error messages, scrolling the useful information off the screen.
(The console screen driver does not support back scrolling.)
The localization of many errors is poor.
The Western Electric assumption that users will browse through the
source code for relevant examples necessary to understand the documentation
pervades this binary only system.
Machine readable copies should be provided for the
examples that are included in the manuals.
The examples should be actual working programs or drivers,
not dysfunctioal "generic examples" with critical coding
(and the concepts contained therein) removed.
Microsoft provides working examples for Windows: Why not for Xenix?
A particular problem is the total lack of documentation on
the 286\'s segmented kernel addressing
and how to make
GDT and LDT entries
necessary to address device buffers.
Processing speed for small model programs
is excellent with a 9 mHz PC-AT (18 mHz crystal).
The kernel service time (getpid()) is about 170 us, an excellent figure.
With 1152k, vi is still quite responsive even when net news is being unpacked.
File system fragmentation does take its toll on Xenix, however.
C compiles have slowed down 30 per cent, and vi startup has become sluggish.
The normal solution to file system fragmentation problems, a dump/mkfs/restor
cycle, can't be used on Xenix until Microsoft provides working programs.
PC-AT Xenix can drive a color and monochrome monitor independently.
The second monitor can be used for monitoring UUCP, make\'s, or
for debugging screen oriented programs.
The shell script
"$@ >/dev/color 2>&1"
(named color)
allows commands such as "color make&" to output their progress on
the color monitor while allowing unimpeded use of the monochrome
CRT for editing.
Xenix has some useful enhancements over Vanilla Unix.
The following program immediately shuts down Xenix if run as
super user.
".root bibi" is useful for switching to DOS and back as quickly as
possible.
.nf
/*
* bibi.c shuts down a XENIX for PC-AT RIGHT NOW.
*/
#include <sys/param.h>
#include <sys/filsys.h>
main()
{
shutdn( (struct filsys *) 0);
write(2, "Raised from the Dead\n", 21);
}
.fi
.DF
A DOS emulator would be much more useful.
The following program allows one to become superuser.
(It works on most flavors of Unix.)
It must be chown root and then chmod u+s to be effective.
With it you can give a command ".root bibi" to shut the
system down quickly.
It should be placed in a directory accessible only to you.
.nf
/*% cc -K -O % -o root
* Run command as superuser.
* Become root. Then exec to command given by
* argv[1] with arguments argv[2]...
* If no arguments, call a shell as root
*/
main(argc, argv)
register char *argv[];
{
setuid(0);
setgid(0);
ulimit(2, 30000000);
umask(0000);
if (argc >= 2)
execvp(argv[1], &argv[1]);
else
execl("/bin/sh","sh",0);
write(2, "root: can\'t exec\n", 17);
return (3);
}
.fi
.H 1 "Weak Points"
.DF
Xenix does not provide any job control or any multi-tasking
window support.
This means the computer is effectively a single process system
when doing the numerous lengthy multi floppy transfers necessary to back up
programs and data..
.DF
There is no autoboot on powerup option.
Well, there is in the maintenance release - it defaults to hd/xenix
of nothing is typed after a minute.
/.profile or something needs to be modified along the same lines.
.BG
There is no facility for dealing with disk blocks which go bad
after Xenix in installed save archiving all pertinent files
on floppies and starting over with a new copy of Xenix.
.BG
Xenix installation blanks out entire disk tracks at a time,
even when only one block in an entire track is bad.
The PC-AT hard disk uses processor instructions to transfer
data to and from memory.
This has little effect on file access to random blocks,
but swapping is much slower than standard Unix systems.
Sticky bits don\'t help much either.
On a 640k system, a nice\'d make(1) causes vi to lurch, occasionally
swapping out for several seconds.
This causes frustration and increases the keyboarding error rate.\*F
.FS
Such variability in response time makes users think the system is
slow or unreliable, even if the long delays are infrequent.
.FE
When estimating total memory requirements for the PC-AT,
figure on twice the memory per user process
compared to a PDP-11/45 runing V7 Unix.
.BG
The system has broken out with pages of hard disk error reports.
Cycling power cleared the problem.
This has happened three times, and it\'s enough to put
the Fear of God into users.
The new disk driver (part of the maintenance upgrade) still has this problem.
.BG
One one occasion the disk driver and/or hardware went into a
"funk" and cheerfully and without complaint
wrote unreadable tar images to floppies.
Again, cycling power cleared this problem.
Caveat Emptor.
.BG
On another occasion, tar wrote an archive without complaint, but
attempts to list its contents (tar tvf) got only a "tar blocksize"
response.
This time reformatting the disk and trying again were enough to
get a good archive (reboot not necessary).
Caveat Emptor.
.BG
The tar
.B u
(update) key elicits a "tape read error"
on a valid floppy disk tar archive:
"tar uf /dev/rfd1 directory"
fails but
"tar tf /dev/rfd1"
works.
.BG
Error recovery on hard disk errors leaves much to be desired.
A 200k file with a intermittently bad block at 49k provided some
useful insights into Xenix\'s hard disk driver.
With wc(1) or grep(1), the bad block sometimes shows up,
accompanied by two "err on dev ..." printouts
that scroll off the console screen.
.BG
Neither wc nor grep
complained about a disk read error, they just quit silently!
Once, there was only one "err on dev ..." printout and wc read through
the entire 200k file.
This suggests the HD driver on Xenix
complains on the last two retries.
Whether it tries more than twice
cannot be said, but it doesn\'t try too hard since manually rereading the
file once or twice will read it successfully.
Two other files had "intermittent bad blocks" which would fail
some of times the file was accessed and succeed other times.
.BG
The floppy disk format program doesn\'t check for valid operation.
One can "format" a normal disk to 1.2 mb in the HD drive without
errors, but only a third of it can be read back.
.BG
Normal floppy disk writes are not checked either.
The best advice is to completely read the floppies you have just written to
make sure they are readable.
This makes multi volume floppy disk backups incredibly
cumbersome.
.BG
The obvious solution of
.ce 1
dd if=/dev/rfd148ds9 of=/dev/null bs=9b
to verify a 360kb floppy on drive B: elicits a "bad address" message
and causes other programs to core dump until Xenix is rebooted.
Xenix desperately needs a "VERIFY" switch `ala DOS.
Speaking of disk backups raises a sore point. ...
The documentation on restore(1) notes that
"It is not possible to successfully restore an entire active root file system."
No such warning is made in the documentation on backup(1) (`aka dump(1)).
The implication is that these programs will operate properly on
an inactive root file system, such as when Xenix is in system maintenance
mode.
.BG
When I made a level 0 backup, backup cheerfully wrote out out five HD
diskettes.
Unfortunately, dumpdir coredumps when trying to read this archive,
and restor wouldn't restore a good file system from these disks.
.BG
Life was slightly better with the /usr file system, except that backup
skipped all files and subdirectories to /usr/lib.
The resulting filesystem ended up with a cyclical data structure,
a directory indirectly linked to itself.
.BG
After discovering (the hard way!) about backup/restor\'s problems
dealing with a root file system, I tried dd.
A first dry run (dd if=/dev/root of=/dev/null bs=10k) seemed to work
normally, but succeeding dd commands resulted in a variable, smaller
number of records transferred and eventually core dumps.
By this time things had gotten so far out of hand that the shell
itself was tossing cookies.
.BG
The crontab line
.br
0,10,20,30,40,50 * * * * /etc/dmesg - >>/usr/adm/messages
.br
is supposed to append error messages such as those from the hard disk
to the specified file.
It doesn\'t.
.BG
Xenix does not adjust the time of day for Daylight Savings Time
as does V7 Unix.
.DF
System error messages are currently written to the console CRT,
where they often scroll off without being read.
There should be a way to make the low level error messages output to
a serial or parallel port, to a cheap, slow printer used just for
logging.
.BG
After the system has been running for a while, cron uses up its
default ulimit for writing disk files and programs called by cron
begin to fail.
There should be a way of setting the default ulimit to a very high
value that will not be exceeded before the system is rebooted.
According to documentation, a ulimit command in /etc/rc should do
the trick, but it doesn\'t.
.BG
The shell cannot recover from a "no space" condition encountered
during filename expansion with the `prog` construct.
Xenix comes with a set of programs to manipulate DOS disk files
on floppies.
.DF
No program is provided to manipulate DOS files on a hard disk
or partition.
.DF
No command is provided to format DOS floppy disks.
.DF
Copying files to DOS with the doscp program, filenames are translated
to upper case.
.BG
The doscp program copies Unix directories to DOS disks as
regular files.
.DF
DOS disk filenames must be referenced in upper case, and are
not converted to lower case when transferred to Xenix.
.br
.BG
The examples given in the manual won\'t work
because of the upper case problem.\*F
.FS
The new IBM manuals have the same error.
.FE
.DF
Wildcard filenames on DOS disks are not supported; the "match" subroutine
from cpio(1) could have been included with little effort.
.br
.BG
The file modification times are lost when files are transferred to DOS,
and again when transferred to Xenix.
.DF
File transfers are much slower than with DOS.
A professional programmer could complete these programs in about a
day\'s time.
Sometimes\*F it seems these programs\' limitations are typical of the
non Bell V7 portions of Xenix.
.FS
During periods of frustration.
.FE
.BG
The system crashes when power is cycled on a Gemini-10 printer
when a file is being output to the printer.\*F
.FS
It sometimes does not crash if power to the printer is cycled while no file
is being printed.
.FE
Unfortunately, this is the only way to reset most printers
(before they eject twenty sheets or jam themselves)
when they are sent an improper file.
IBM claims none of their printers cause this problem, and so refuse to
"accept" a bug report on it.
If you will be using Xenix with a line printer, be sure to
check this out with your printer.
The parallel ports on an AST Megaplus II and a Paradise Systems
Multidisplay card work properly with DOS but not with Xenix.
Only the IBM parallel port (supplied with the PC-AT)
and the parallel port on an IBM monochrome board worked.
.BG
Lpr sometimes hangs while printing.
Rebooting Xenix corrects the problem.
This may be due due to a reported logic error on the IBM parallel adapter
supplied with the extended PC-AT, but I have not received any information
about revisions for this board.
The Tigard Computerland service department has not heard of any parallel port
engineering change orders.
It does appear possible to drive two printer ports,
but an off line or power down condition on one of the ports usually hangs
the other printer port after a few characters have been printed.
Doing so may confuse the system (it happened only once so far,
and the exact cause of the crash is unclear).
There is no documented way to cancel/abort requests to the
printer spooler.
The only sure fire way is to clear out the /usr/spool/lpd directory,
cycle power on the printer, and reboot when Xenix crashes.
The spooler supports only one output device.\*F
.FS
A background program may output to the other device(s).
.FE
.BG
The command "lpr file"
.B silently
refuses to work if the file
(and possibly the directories leading to it)
are not generally readable.
Lpr(1) should complain about unreadable files.
The assembler generates 0600 mode listing files unreadable by lpr.
.BG
Lpr corrupts printer escape sequences, including some used by the
IBM graphics printer.
The Xenix C compiler appears to be written from scratch,
not a port of the Ritchie or Johnson compilers.
Some programs that stretch the C language yet
compile satisfactorily under Unix compilers
(and also pass lint(1)) need revisions to compile with this compiler.
Users accustomed to the Lattice C compiler may need some readjustment to
the world of signed characters.
The simple expedient of changing all instances of "char" to "unsigned char"
slightly impairs efficiency and causes all sorts of complaints about
mixing of types.
The following C program gives clues to some of the solutions.
In other cases, the byte must be explicitly masked with an 0377.
.nf
#define SS \'\377\'
#define TT 0377
main()
{
char c; unsigned char u; int x,y,z,w;
c = 0377; u = 0377;
printf("c=%d u=%d SS=%d TT=%d\n", c, u, SS, TT);
/* c=-1 u=255 SS=-1 TT=255 */
x = c == SS; y = c == TT;
z = u == SS; w = u == TT;
printf("xyzw %d %d %d %d\n", x, y, z, w);
/* xyzw 1 0 0 1 */
}
.fi
.BG
The library function isspace regards many of the PC\'s function key codes\*F
.FS
When used in a DOS program that encodes the function keys by setting the
8th bit.
.FE
as white space.
Workaround: write your own isspace function.
.BG
The DOS "system" function always returns 0,
not the exit status of the called program.
.BG
Copy(1) flattens directory trees when told to
.br
"copy -rl sourcedir destdir".
.BG
Strip(1) abends when it discovers a file with a bad magic number
(i.e., a shall script, etc.).
.BG
Strip is not smart enough to recognize a file that has been
already stripped.
This wastes time when attempting to strip
all files in a directory.
The Unix strip(1) passes over such files, allowing "strip *" to
strip all suitable files in a directory.
.BG
The C compiler
large model code is reasonably tight, but all programs that needed large
model cause the compiler to abend with failed consistency checks.
The one program that needed the large model and did compile and work properly
had (according to its comments) compiled with DeSmet C small model!
.BG
Xenix\'s large model is not as large as the Lattice C large model;
it cannot deal with objects larger than 64k.
None of the Xenix commands were compiled with the large model,
even though some user programs cannot be compiled or lint\'ed because of
small model memory limitations.
.DF
The warning messages generated by #undef\'s on undefined preprocessor
symbols provide no useful information.
They (and the clutter they generate)
should be eliminated to save screen space for useful diagnostics.
.BG
The C library does not seem to be optimized
(jumps to $+2 not removed).
.BG
Xenix programs compiled on PC-AT Xenix will not run on
PC-XT, Compaq, and AT&T 6300 Xenix and PC-IX systems.\*F
.FS
Because the library functions use 286 specific instructions.
.FE
Since most installed Xenix systems currently run on these other processors,\*F
.FS
With PC-AT delivery problems, and the resultant user community distrust
of this product, this situation will persist for some time.
.FE
the lack of compatible libraries negates PC-AT Xenix\'s usefulness for
software development.
.BG
The linker and ar(1) don't always agree
as to what is a proper library format.\*F
.FS
The secret is to apply ranlib(1) to the output of ar(1).
This is not a requirement in V7 Unix.
Ranlib is not even present in SYS III Unix.
This "gotcha" is mentioned only in the ld(1) documentation,
which few users will ever see since they don\'t call it directly.
It should be mentioned or alluded to in the ar(1) and cc(1) documentation,
including the error message explanation.
.FE
.DF
Stack use on the 286 is problematical because the chip\'s
built in memory management
does not support stack growth.
The user must predict at link time how much space to allocate to the
stack.
This space cannot be used for the heap.
Xenix provides a stackuse program to estimate stack usage, but it abended
on some of the programs I tried it on.
I don\'t know what stackuse(1) will do for recursive programs whose stack use
depends on the input data.\*F
.FS
When I attempted to run stackuse on it, I got hard disk errors.
Film at 11.
.FE
This stack use is a real time bomb as it may not show up until
months after the program has been compiled and tested.
Large model programs could in theory use a dynamically sized stack
segment, but there is no evidence this is supported.
The question is academic since large model compilation hasn\'t
worked for any non trivial programs.
The documentation does not clearly describe the effect of the
C compiler\'s -F option.
There doesn\'t seem to be any effect for small model DOS programs.
They always seem to allocate maximum stack space with the stack starting at
the highest address in the data segment.
The -pack and -m0 options are not documented.
Even in the Microsoft Windows documentation,
The -pack option was not well documented,
appearing to describe bit packing `ala Pascal.
(The -pack option assigns
storage locations at the first available byte address,
equivalent to Lattice C -b option.)
.BG
The post optimizer fails on at least one function per major program
as it exhausts memory on a 1 megabyte PC-AT.
This is unconscionable in light of Intel\'s and IBM\'s hype about
the 286\'s 4 gigabyte virtual addressing space.
Do VAX bytes store more bits than 80286 bytes ?
Several shortcomings seriously limit the usefulness of the DOS
cross development system for users considering changing over from
Lattice C or Computer Innovations C86.
.BL
.LI
No source is provided for the C runtime startup routine.
Many serious applications need a modified startup routine.
.LI
No support for objects larger than 64k
such as provided by the Lattice large model.
.LI
No support for printf with output directed to user supplied
functions.
Using sprintf is unsatisfactory.
.LI
No source to library functions.
.LI
Lack of timely response to bug reports.
.LE
.BG
The lack of _doprint (a form of printf with a user supplied output function)
forces developers to use such hacks as calling sprintf with assumed
calling arguments, and to store the output in a temporary array.
Such a restriction compromises speed and robustness.
This is but one of many instances where lack of documentation, critical
sections of source code, and standard (if not always documented)
Unix interfaces hobbles the development of serious applications.
.BG
Lint often runs out of memory, even on programs which compile.
.BG
Lint reports incorrect line numbers when flagging errors on most files.
This is NOT a problem with Lint on V7 PDP-11\'s and Sys III on Plexus.
Lint tends to core dump or abend on files, even some that compile
without fatal errors.
.BG
Since Lint uses a front end completely different from the C compiler,
a different set of errors is sometimes detected.
.BG
Lint thinks putchar() and getchar() have a null effect.
.BG
The lint curses library is missing.
.BG
cb(1) munges multi-line #defines:
.nf
/*
* From the original file
*/
#define BADCH (int)'?'
#define EMSG ""
#define tell(s) fputs(*nargv,stderr);fputs(s,stderr); \\
fputc(optopt,stderr);fputc('\n',stderr);return(BADCH);
/*
* Output of /bin/cb
*/
#define BADCH (int)'?'
#define EMSG ""
#define tell(s) fputs(*nargv,stderr);fputs(s,stderr); \\
fputc(optopt,stderr);
fputc('\n',stderr);
.br
.fi
.BG
The visual editor (vi) runs out of memory trying to edit a file of
50803 characters, despite the 80286\'s claimed 4 gigabyte address space.\*F
.FS
There is a hack available to allow vi to use more memory.
.FE
When vi runs out of memory, it suggests you use ed.
On some files, ed runs out of memory space also, but does not suggest
what to use (CP/M\(Tm?).
The obvious answer to SYS III users if bfs(1), but it abends
complaining about lines too long when searching through
nroff(1) output.
It seems Xenix can\'t talk to itself.
.BG
Malloc(3) and sbrk(2) fail
if called with an argument of more than about 30 to 32 kb
in both small and large models.
A getml function (`ala Lattice C) is needed to allocate objects
larger than 64kb to support Lattice C and other large model programs.
.BG
Contrary to the documentation, the "nap" function does not always pause
at least as long as the argument requires.
In particular, nap(1) to nap(19) return immediately while nap(20)
waits the proper 20 milliseconds.
.BG
The primitive CRT emulation does not always display properly while inserting
with vi(1).
The small underline cursor is difficult to locate on a busy screen;
All the display adapters can be switched to blinking block cursor,\*F but, alas,
Xenix can\'t.
.FS
Termcap has fields for setting a terminal to block cursor
during visual mode.
.FE
.BG
When passing a large file through a filter (1,$ !filter),
vi(1) munges the file with a mess of blank lines replacing some of
the file contents.
.BG
The vi undo command often refuses to undo the last modification.
I find the the AT\'s escape key location cumbersome, and often
hit backspace when intending escape.
I solved the problem on DOS by swapping some keys with software
reassignment.
Unfortunately, the keyboard support on PC-AT Xenix is much too primitive
to support this.
.DF
UUCP is "vanilla", apparently without any of the accepted
extensions, such as the uux -z option.
.BG
There does not seem to be any way to set the node name returned by
uname(2).
.BG
The keyboard F1-F40 and ALT-1 to ALT-Z keys do not generate unique
codes.
Most of these keys don\'t do anything at all.
The Ctrl-Break and Shift-PrtSc keys don\'t work.
.BG
The serial port tty00 (connected to the IBM AT parallel/serial board)
tends to go dead.
The enable(1) and disable(1) commands caused some garbage to be output
from the port, but the system had to be rebooted to get the port back
on the air.
An open line on port tty00 with a 9600 bps getty
brings the system nearly to its knees,
increasing the run time of compute bound programs by factor of 300
per cent.
Vi is frustratingly sluggish under these conditions.
.BG
It is apparently impossible to set a tty port to a 9600 baud getty
without Xenix thinking that port is dedicated to an IBM 3101 terminal.
In particular, the "6" argument to getty doesn\'t work per the manual.
When one logs into that port, Xenix prints some garbage (apparently
3101 initializations).
.BG
Stty ff1 does not generate the documented one second delay on form feed.
The 256 character limit on buffer utilization by incoming serial data
causes delays and/or loss of data in telecommunications applications.
Basica allows more buffering; why not the higher priced spread?
It is unfortunate that this problem, and the ff1 bug, are not in the
device driver source code, where a user could correct them.
.BG
In Unix System III, the raw input is affected by the c_cc array in
the terminfo structure.
VMIN sets the minimum number of characters required to satisfy a
read request.
VMIN doesn\'t work when set to 133.
Since the TTY(M) manual entry dosen\'t
say anything about VMIN, it is possible that Microsoft didn\'t
get around to making VMIN work.\*F
.FS
IT appears that VMIN affects the keyboard, but not the tty ports.
.FE
If that is the case, VMIN should have been removed from termio.h,
and Microsoft and IBM shouldn\'t talk about Unix System III compatibility.
.BG
Xenix also has problems with the
O_NDELAY
attribute in fcntl(2) and open(2) calls.
When
O_NDELAY
is set on the keyboard, read requests return 0
regardless of what has been keyboarded.
This behaviour breaks programs that work properly on true SYSTEM III Unix
as well as Regulus.
In addition, if a tty line is opened with
O_NDELAY
set, it can\'t be turned off.\*F
.FS
This can be worked around with separate file descriptors.
.FE
I have a suspicion that these problems arise because Xenix
attempts to track Bell developments (SYS III, etc.)
by hacking Microsoft\'s modified V7 sources
rather than porting
the new versions directly.
Subtleties in Bell\'s code
that make or break applications
don\'t always find their way into Xenix.
.BG
Xenix totally ignores most of the function keys.
Xenix should return the same function codes as described in the
"Technical Reference Manual".
Each function and ALT- key should return a unique sequence
as it does in the ROM BIOS and PC-DOS.
They should not depend on any escape strings sent to the console
driver, especially since those settings tend to to disappear.
.BG
The non-standard method of assigning strings to function keys
F1-F10 are often forgotten.
.BG
When output is redirected to the color monitor,
the function key definitions print on the screen as garbage.
.BG
The stock uucico calls a separate program "dial" to command an intelligent
modem to dial up a call.
Unfortunately, uucico does not allow "dial" enough time to place a data
call where pulse dialing, long distance, or modems which require
extra commands are involved.
The only solution so far is to use a custom uucico compiled from
sources not supplied with Xenix.
The stock L.sys "microsoft" entry contains the area 205 directory
assistance phone number.
Customers frustrated by poor response to bug reports will find this
private joke to be in poor taste.
Documentation on the
V7 phys(2) call is missing; such a call would allow user
programs to bypass many of Xenix\'s limitations.
.BG
None of the V7 or SYS III graphics support is present, including
tc(1) necessary to preview troff output.
.BG
F77, struct, snobol, and basic/bs are missing.
The Xenix Ratfor claims to produce C source code.
Too bad they left out V7\'s struct(1) which converts fortran to ratfor.
.BG
Crypt is missing from the C library.
In fact, there doesn\'t seem to be any crypt function of any sort
in Xenix.
Again, Caveat Emptor.
.BG
/usr/include/stdio.h does not declare popen as a function returning
a pointer to FILE.
.BG
Neither nroff or troff support the features of current printers such
as the Diablo 630, HP LaserJet, Epson, Okidata, or even the IBM PC Printers.
In fact, Xenix supports
.B none
of the 32 modern printers supported by Microsoft Word 1.15.
Xenix does support the 10 character per second upper case
only Teletype\(Tm model 33 teleprinter introduced not too long after
the hula hoop craze.
The Xenix documentation does not describe any of the troff fonts,
or even mention what device the troff output is intended
for, let alone how to convert the output to something useful.
If in doubt, consult the source code.
The "Text Formatting Guide" introduction promises to help generate
an index for a document, but fails to mention how this might be accomplished.
The ptx(1) manual entry is as opaque as the Bell version, but there is
no source code that can be perused to divine its application.
.BG
The make(1) sequence
.br
ymodem.doc:yproto.mm mdmenh.mi xmcrc.mi Makefile vers.mi
.br
mm -t -c -u0 -rB1 -rO0 -rW74 yproto.mm >ymodem.doc
.br
fails to process the table commands in the file xmcrc.mi,
despite their being enveloped in a .DF/.DE pair as suggested by
the mm documentation.
.BG
The mm comand -c flag doesn't invoke col.
.BG
When the table file is separately processed by tbl -TX and the
resulting output included with an .so statement, nroff -mm
munges the table formatting.
The tbl/nroff processing works properly if the mm macros are not used,
but that is useless.
.BG
Spell(1) doesn\'t words such as doesn\'t in nroff source.
The Unix manuals are rearranged according to the unbundling of the
Xenix compiler and text processing software.
Manual entries are difficult to
find because they aren\'t always where one expects them to be.
For example, the compiler manual entry is in the "XENIX Software
Command Reference", but the link editor is described in another book.
Subroutines and systems calls are described in the
"XENIX Software Command Reference", but the tty(4) control codes
used with ioctl(2) are back in the "XENIX Command Reference".
One would associate strip(1) with the linker, OOPS, it\'s in
the book with the compiler, not with the linker ...
The standard Unix manual organization of section 1..8 is MUCH better
and should have been preserved!
In the manual on nroff, troff, etc., the section numbers in
the individual articles have been removed, making the documents
cumbersome to use.
Since these will be the only Unix documents seen
by many people new to the world of Unix,
Microsoft owes it to the Unix community to get them right.
Experienced Unix programmers will hang on to their Bell manuals,
even if they don\'t describe Xenix exactly.
Others will just complain about Unix\'s legendary poor documentation.
.H 1 "Program Porting Scoreboard"
This is a scoreboard of how various application programs fared
in porting to Xenix for the PC-AT.
.VL 9
.LI compress
(From net.sources)
The large model is again useless.
The "pdp11" flag must be used to generate a working program.
Most compressed files use 16 bit codes, but the Intel small model
can\'t handle more than 12 bit codes.
With a small amount of hacking, the program can be made to
work under DOS.
.LI wator
(Modified "game of life" simulation from net.sources)
One of the modules was called "screen_control.c" when written on a
4.2 BSD system.
This was silently truncated to "screen_control" when dearchived to Xenix
via shell output redirection.
Then the C compiler silently overwrote the source file with the
object file the first time it was compiled.
To add to the confusion, make(1) failed to notice the source file
had been overwritten by the object module\*F.
.FS
screen_control.o: screen_control.c wator.h
.br
$(CC) $(CFLAGS) -c screen_control.c
.FE
Apparently make doesn\'t recompile if the two files have the same
time - seems to be a bug.
This program seems to work properly once syntax errors,
incorrect file names,
and the like were corrected.
Xenix C sometimes doesn\'t recognize
.cu
char *foo [10];
because of the space between "foo" and "[".\*F
.FS
Such constructs are legal C (see "Lexical Conventions" in section 2
of K&R\'s C reference manual), but what\'s a space between friends ?
.FE
This is about the only nontrivial program that has ported to PC-AT Xenix
without major problems.
.LI rn
(Advanced news reader from net.sources)
Compiler abends with internal consistency checks.
Lint is useless.
The maintenance release compiler still abends on some of the modules.
Rn is now running after commenting out the features whose code caused
the compiler to abend.
.LI scame
(Screen editor from net.sources)
Scame eventually compiled and appears to operate properly.
The program allows several files to be edited at the the same time
using windows.
A working huge model compiler is needed to make scame a useful program
that can edit reasonably large files.
.LI jove
(EMACS like editor)
Jove uses calls to _doprnt, a function supplied in V7 and SYS III Unix
but missing from Xenix.
.LI hack
(Screen oriented game from net.sources)
The compiler abends with internal consistency checks.
Lint was useless.
Hack was ported to the PC under DOS using the Lattice C large model
and a Curses package with little trouble.
.LI "PC-IX hack"
(From Usenet 6-85)
This version of Hack ported fairly easily to Xenix once the right include
files were specified for hack.io.c and some #defines in hack.monst.c
were changed.
The latter change was required to silence the very informative complaint:
.br
Compiler error (assertion): file @(#)omf.c:1.17, line 239 source=-1
.br
.LI sq
(file squeezer with machine independent output)
The statement
.ce
(((UNSIGNED)~0) >> (16 - level)));
resulted in a signed shift.
After a hard day\'s hacking to identify the problem,
the statement was recoded as an array reference.
A May 1985 copy of the Microsoft C compiler for DOS still had this problem
which was reported to IBM and Microsoft in December and January.
.LI shar
(Shell archive generator from net.sources)
Compiled with no problems.
.LI netnews
(Network news from net.sources Rev 9/5/84)
The large model doesn\'t work, so define the "pdp11" flag.
The C compiler does not accept commands such as
.br
cc -O -Dpdp11 -DUSG -Dindex=strchr -Drindex=strrchr\\
-DRNEWS=\\"/usr/bin/rnews\\" -DSPOOLDIR=\\"/usr/spool/news\\" \\
-DBATCHDIR=\\"/usr/spool/batch\\" -DLIBDIR=\\"/usr/lib/news\\" \\
-DBINDIR=\\"/usr/bin\\" -DNEWSUSR=\\"news\\" -DNEWSGRP=\\"news\\" \\
-DREAD -c pathinit.c
.br
with the informative error message:
.br
(0) : FATAL : bad flag = D
.br
Apparently the compiler doesn\'t accept such a long command line.
The solution is to place the "index" and "rindex" definitions
into /usr/include/stdio.h
and remove them from Makefile\*F to make room for the rest of the
definitions.
.FS
One good crock deserves another.
.FE
This problem also showed up when attempting to change the defined
mail program in recnews according to the recommended procedure.
You\'ll need up to date version of uucp that accepts "uux -x -c".
You\'ll have to get a copy of crypt.c (normally supplied in the C library)
to link the software.
For some reason make(1) insists on recompiling several files that don\'t
need to be recompiled.\*F
.FS
See figure 1
.FE
As is the case for several other important programs (vi, C post-optimizer,
lint, etc.) it would indeed be great if Microsoft could make some more
of the 286\'s 4 gigabyte virtual address space usable.
Error statements such as
"Make: Cannot alloc mem for envp.. Stop."
.br
make one wish for a 68000 based system.
There were other little gliches and gotchas.
Some of them were legitimate bugs that Microsoft\'s home grown
C compiler wouldn\'t accept.
If your newsfeed uses batching with compression, make sure they
limit their compress to 12 bits until Xenix figures out how to
access more than 65k of the 286\'s claimed 4 gigabyte address space.
Vnews seems to work best for reading the news, primarily because the
built in paging software eliminates readnews\'s delay in starting
up a pager.
The new (1/85) distribution of vnews builds a library of functions.
Unfortunately, several attempts (including using lorder(1) according
to the ar(1) manual entry) ended with complaints about an
Error in accessing the library.
The documentation helpfully reveals that this error message is the result
of an invalid library, but does not suggest how to build a valid one.
The secret is to apply ranlib(1) to it.
There is no mention of this in the documentation on ar(1).
The ld(1) documentation discusses it, but many will not see this
because they never call ld directly.
The ar(1) entry should mention that ranlib(1) is needed to clean up its act.
Besides that, Xenix is supposed to be a SYS III implementation, and SYS III
doesn\'t have ranlib!
After processing the rlib.a file with ranlib, it was necessary to explicitly
include "bfr.o" as this file had somehow leaked out of the library.
The new vnews seems to be working, but there are some strangenesses left.
The afbuild program, which builds a database of article information,
runs out of memory if more than a hundred or two articles are present.
This number of articles is easily reached.
The usual comments about the large model apply here.
.LI Battlestar
(From net.sources)
Some of the files in this program cause the compiler to core dump.
.LI Sail
(From net.sources)
Some of the files in this program cause the compiler to core dump.
Isn\'t this wonderful?
.LI Kermit
Several files in the 2/85 Unix Kermit caused the compiler to
toss cookies and do other nasty things.
Perhaps Xenix doesn\'t really need Kermit, uucp works so well:-)
.LI pi
(From net.sources)
This DeSmet C program is the only program more than a dozen or so lines long
that has ever worked with the Xenix large model.\*F
.FS
At this site.
.FE
That is not great praise for Xenix\'s large model because DeSmet C
compiled and ran it using the small model.
.LI slphang
(From net.sources)
This program tests for a bug in the alarm and pause calls in various
versions of Unix.
The program ran properly after the variable "delay" was
changed to a long.
Oh yes, the program does hang - within about 10 seconds.
Since this particular problem appears endemic to all non Berkeley
versions of Unix, I\'m not counting this one as a Xenix bug.
.LI desmods
(encrypt/decrypt bytes using the NBS DES algorithm.
Programmed by R.W.Outerbridge; uses Jim Gillogly's DES.)
This program touts itself as running on almost any good K&R compiler,
including CP/M versions.
It compiled without change or error, and printed gibberish on the screen
(as expected) when encrypting keyboard input.
I haven't tested it any further yet.
.LI sun
This program reports sunrise, sunset and the angle of the sun.
The program was posted on Usenet.
The Xenix header files did not properly declare time() and localtime().
A couple of ints were changed to longs to prevent loss of information.
Even with the indicated changes, the program prints ridiculous numbers
when compiled with the maintenance compiler.
.LE
.H 1 "Support"
When Microsoft offered PC-AT Xenix for sale to ISV\'s
(Independent Software Vendors).
One of the conditions of sale was:
.in +16
.rm -16
"1. Support for the product will be provided by an IBM hotline."
.rm +16
.in -16
Most people would interpret that sentence to mean that the IBM hotline
would provide bug fixes or acceptable workarounds to reported bugs.
Popular conception as well as the book "Search for Excellence"
maintain that IBM\'s strong point is excellent customer service.
Unfortunately,
the staff at the "IBM Xenix Software Hotline" has proven
to be inexperienced in most aspects of Xenix save that IBM
cannot accept any source code (for bug reports) without a
written oath on the outside of the package
that the code sample contains nothing of interest to
third parties.
In the more than forty hours that I have spent tracking down Xenix
bugs and educating the IBM staff on the Basics of Unix,
none of the reported bugs have been corrected.
The ultimate insult is a letter from a J. P. Rollman dated January 16
1985 stating:
.in +8
.rm -8
"As a licnesee of the preliminary version of Xenix, you were given the
opportunity to get questions answered by using the Engineering
Scientific Hotline.
With the formal release of Xenix on January 4, 1985, the Engineering
Scientific Hotline will discontinue Xenix support on January 31, 1985.
I want to thank you for participating in this program."
.in -8
.rm +8
As of this date NONE of the reported Xenix bugs has been fixed
as a result of bug reports made to this hotline.
The "support" provided in connection with this hotline had, in fact,
consisted entirely of training for the staff of
IBM, a multi billion dollar corporation!
It\'s nice that Mr. Rollman should wish to thank us for this training.
Considering that none of the bugs were fixed, payment of consulting fees
would be more appropriate.
.H 1 "Postscript"
I got a call (2-22-85) from Mr. Tondo at IBM concerning Xenix and all its glory.
The caller was knowledgeable about Xenix and indicated a "maintenance release"
was in the works.
We went over most of the bugs mentioned here and he understood them all!
He also understood the need for direct screen access, huge model, etc.
There is hope yet for PC-AT Xenix.
A letter dated March 8 from Steve Wright, Microsoft Xenix product marketing,
promised an update disk to be shipped in early April.
I received an update disk May 11.
It fixed vi\'s stack allocation problem and provided a new version of the
compiler and libraries.
The new compiler is slightly less buggy than the previous one.
The memory layout of programs cross compiled to DOS has been changed
without any documentation, breaking existing code.
The dos system function now causes strange behavior after it returns.
Fortunately I was able to replace it with a public domain subroutine
that saved considerable memory and eliminated a restriction as well.
The large model has yet to work for any program that really needs it.
About the only thing that can be said for it is that you can save quite
a bit of disk space by removing the large model libraries.
.H 1 "IBM Version of Xenix"
A IBM service representative claimed that the pre-release bugs were
corrected before IBM started selling Xenix.
Others have told me that the Microsoft version was identical to that
being sold by IBM.
As mentioned above, only a few of the bugs were fixed by the maintenance disks
shipped in May 1985, and some new bugs and/or undocumented gotcha\'s
were added.
You will have to decide what to believe.
Be careful if you state has passed one of the
"Shrink Wrap Software Laws" quietly finding their way onto the books.
.H 1 "New Version"
On July 1 1985
I called C. L. Tondo who had previously indicated I
would be a Beta
test site for the System V version of PC-AT Xenix.
He indicated that IBM has decided against external test sites for SYS V
Xenix because of two month\'s worth of red tape that would be involved.
The image of Microsoft and IBM software
quality and product support will undoubtedly
remain unchanged.
.H 1 "Hardware Configuration:
.br
Extended PC-AT with type 2 disk
.br
COM1 connected to Tektronix 4014 or IBM PC
The serial port input level converter was modified to revert to marking
when no RS-232 input is present.
.br
LPT0 connected to Gemini-10X
.br
IBM Monochrome display adapter, Dynax DX15 Daisywheel printer
.br
Paradise Systems Multidisplay card configured as color adapter, RGB monitor.
.br
AST Advantage! with 640k installed (COM2),
Hayes Smartmodem 1200 external modem
.SG
.CS
.TC
--
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131
Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231
Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect)
Home of Professional-YAM, the most powerful COMM program for the IBM PC