Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!rlgvax!hadron!netexa!rfrye
From: rfrye@netexa.UUCP (Rob Frye)
Newsgroups: net.unix,net.unix-wizards
Subject: Re: XENIX System V Release 2.0 for PC/AT Problems in Device Driver Installation
Message-ID: <142@netexa.UUCP>
Date: Fri, 14-Mar-86 16:13:40 EST
Article-I.D.: netexa.142
Posted: Fri Mar 14 16:13:40 1986
Date-Received: Mon, 17-Mar-86 03:25:11 EST
References: <381@weitek.UUCP>
Distribution: na
Organization: NetExpress, Inc., Vienna, VA
Lines: 63
Xref: watmath net.unix:7398 net.unix-wizards:17238

> I am trying to add a device driver to XENIX System V on an IBM PC/AT.
> I have run into several problems.  
> 
> Problem 1)  The most serious problem is that 
> when I load in any code, even irrelevant code which would never be 
> referenced by any other routine, PS stops working.
...
> boot
> :/usr/sys/conf/xenix		{This is the new xenix}
> 
> Then after some initialization, we are in the new XENIX.
> Now, ps gives the following message.
> 
> # ps
>    PID TTY TIME COMMAND
> ps: seek error
> #

If indeed you just typed "ps", then the answer is simple: ps opens up
/xenix to get at the namelist [which is one reason you NEVER strip
the kernel executable] so it can do the correct open and lseek on
/dev/kmem to actually read the current process table.  If you are
not using /xenix as your kernel, then you need to do "ps -n filename";
ie, "ps -n /usr/sys/conf/xenix" so it can do the right thing...

> Problem 2)  make space.o fails.  The cc compiler complains that it is out
> of heap space.  This is true even if no changes have been made to space.c.

Microsoft's C compiler has a few interesting bugs.  See if you have the
undocumented "hdr" and "fixhdr" commands -- they are very usefull and give
a decent "usage" with no args.  If so, "fixhdr" the stack size on the
various /lib/cp? executables.  Unfortunately, I can't remember the lowest
stack size that is useful yet increases the "heap space".  Also, some
files have preprocessor problems that can be gotten around via:
# cc -P file.c
# mv file.i tmp.c
# cc -c tmp.c
Other bugs are an unresolved one creating wrong indirect small-model code under
bizarre conditions that have never been unraveled, but it IS repeatable
[we have to compile 1 particular process under an older compiler and
neither they nor we know why, but everything else tried fails], and various
large-model addressing problems which will be fixed ADNRS.

> Problem 3)  The ld command described above does not appear to recognize 
> ../io/lib_io.stubs as a library routine ...

[Sorry, my source machine is currently unavailable to check this, but...]
I think you might have an improper lib_io.stubs -- make sure it is a
proper archive file via "ar" and "ranlib".  Beyond that, I'm no help.

> Problem 4)  The ld command is not completely documented...

Isn't Xenix fun?  Worse yet, I've found some commands that are completely
undocumented (hdr/fixhdr) and some that the doc is WRONG.

Robin Cutshaw, are you still on the net?  Do you have any better info?
-- 
--->
--
"You can Telenet, but you can't tell it much."

				Rob Frye, NetExpress Inc.
				{seismo,rlgvax}!hadron!{netex,netexa}!rfrye