vpix and Xenix/386, part 2

[William E. Davidsen Jr]

  I would like to thank all of the people who sent me suggestions and
information about the problems I had with vpix. I hope that this saga
will help someone else get it running on their system.

 1. I was trying to install a copy of vpix on a Xenix/386 2.2.1 machine.
Following the instructions I went through the procedure, created a vpix
user, and typed vpix. I got a "bad system call" message.

 2. After checking several times, and having people look over my
shoulder, I posted a note on the net. I was not expecting too much of
the product, since I had tried it under another version of UNIX and had
serious problems with the whole product.

 3. I got a number of notes saying "you didn't install UFE1 correctly."
I went back and checked the directions... I have a UFE1 disk, but what
do I do with it?

 4. Ah ha! The sheet of paper marked "Installation Instructions" doesn't
tell how to install the product. The *real* instructions are in the
manual, nice and clear. I have no idea what good the plain sheet of
paper was.

 5. I removed vpix (again), including deleting the permissions file, and
reinstalled the link kit. The I installed the update (UFE1) disk, and
vpix. Every step requires entering the correct serial number and
authorization code.

 6. Now vpix works (it needed some customization to do waht I wanted,
but that's not a product fault at all). When I decided to back
everything up, I found that my tape drive wasn't working, so I reran
"mkdev tape". This doesn't work well with Korn shell, rerun with sh.
Relink, reboot, the tape is known.

 7. The tape is known but not by the values I gave in the mkdev. It's
using the default DMA and interrupt. Also whenever I exit from a virtual
console it dumps me back to the /dev/console screen.

 8. I reran mkdev for serial and tape. No joy. vpix works great,
everything is messed up. The modems won't answer.

 9. I reinstalled my link kit (again), and the upgrade (again), complete
with serial numbers. Then I reinstalled the tape drive and customized
the serial driver. When I linked the kernel everything works.

10. Now I reinstalled vpix and built a new kernel (again). When I booted
I had a complete working system. As I mentioned before the kernel is a
lot smaller than the old kernel. Well smaller on disk but not by 'size.'
This is what I got for disk and real sizes:

+ ls -l /xenix /xenix.tape /xenix.vpix 
-rwxr-xr-x   1 root     root      251146 May 14 23:15 /xenix
-rwxrwxr-x   1 root     root      294417 Apr 23 13:56 /xenix.tape
-rwxr-xr-x   1 root     root      313945 May 14 21:55 /xenix.vpix
+ size /xenix /xenix.tape /xenix.vpix 
/xenix: 200392 + 25136 + 102336 = 327864 = 0x500b8
/xenix.tape: 182572 + 87632 + 0 = 270204 = 0x41f7c
/xenix.vpix: 193804 + 94604 + 0 = 288408 = 0x46698

xenix.tape has tape, no vpix, and vice versa.

Now some comments on the product:
================================

 1. So far it has been adequately reliable. I have had a few cases where
killing the current process also killed the vpix environment, but no
major problems. The programs were doing evil things anyway.

 2. The documentation says that if you comment out the use of the EGAROM
supplied with the package it will use the standard ROM. I tried this and
got a message "can't emulate instruction." This is a standard NEC GB-1,
and it runs fine on an 8088. This means I lose the 640x480 mode, which I
*really* wnated to use. If I can't find a way around I will still need a
real DOS environment.

 3. Programs seem to stop when the DOS screen is not being displayed.
This may be only programs which write directly to the screen or
something, I haven't defined it, but it means using a DOS process as an
idle daemon is out, at least for now.

 4. vpix uses all the spare CPU in the system. On an unloaded system
clock time and CPU are the same. This seems to be done at a low
priority, since a loaded system still runs fine, but I think the DOS
idle loop for reading a char from the keyboard is really still a polling
operation.

 5. vpix uses a lot of virtual terminals. I hope I can control which
ones, as it is grabbing any one without a user or getty at the moment. I
have some system things writing reports to several VTs, and they are the
same ones vpix grabs. The user login uses one, the DOS session uses one,
and I believe the execution of a UNIX command under DOS uses another,
although it may be reusing the DOS screen.

 6. I can't assign a second physical floppy as drive B:. I want the
ability to create 360k floppies which I am really sure will read on an
XT. I got around this by writing them on the 1.2MB drive in 360k format,
then copying /dev/rfd048ds9 to /dev/rfd148ds9. This is not much fun, but
better than no solution. You can have a pseudo B: drive in your own
directory. I haven't tried copy protected disks yet (I just plain don't
use them), but I will.

Blemishes aside, the product is basically useful, and seems robust. It
does protect against ill behaved programs, keeping them from grabbing
the physical hard disk or writing on some disks marked protected. After
a full backup I gritted my teeth and ran a known trojan. Access denied.
This gives me a good way to test for virus programs.

I haven't tried any TSRs, but I don't use them, either. I want to try
MKS toolkit, just to see how a UNIX under DOS under UNIX will work, be
I'm only going to check for trojans and run single applications, so this
is just idle curiosity.
-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me