Bell Tech W.G.E. use with Microport

[Scott Turner]

Well I was patient, I held back my anger, I had a firm grasp on reality and I
knew it would come to my rescue.

Dimitri it seems is living in an alternate universe and his posting somehow made
a hop into this universe. In this other universe I'm evidently not a very nice
person, attacking people and abusing them, asking them to provide support for
things they aren't supposed to provide support for. And above all, no one at
Bell Tech wants to help this alternate universe "me".

I'm happy to say I live in *THIS* universe (this message is not making any
trans-universe hops to reach you), and in this universe all the above is a
crock.

And I'm glad. The complete X10R4 disk set arrived Friday.

We're all happy, the extra source code provided has allowed for a couple
bug fixes to some annoying problems (such as outbitmap -err core dumping)
and provided usage information for others. We're still eagerly searching for
those new impressive images Dimitri said we'd find in the latest release,
so far no sightings but there is alot to dig through.

I guess I can now say we're *HAPPY* with the W.G.E. under Microport Unix
System V/386 3.0e.

There are, as with a rose, a few thorns, but I hope Dimitri will allow sharing
of information about fixing/avoiding them to continue. Without the crap from
his alternate universe residence.

For example:

How to keep outbitmap -err from core dumping... (not core dumping for you you
say? Well read on...)

The -err flag turns on an error propogation algorithm that forwards the error
from converting the current pixel to the three pixels immediately to the right
and underneath the pixel being converted. The problem lies in that the
routine scans ALL pixels in the bitmap... When scanning the rightmost pixel
the routine accesses the first pixels on the next scan lines, tacky but not
fatal. However, when scanning the pixels on the last scan line the routine
access two totally non-malloc'd scan lines. Depending on the size of the image
these last two scan lines may, or may not, fit within the "slop" in the last
allocated data page. If they don't you get a core dump. If they do you get
a picture with a potentially tacky lefthand side.

The fix, go into /usr/new/image/outbitmap.c and patch the two for loops inside
errprop() to scan to "y < (h-1)" and "x < (w-1)".

X10R4 memory usage under Microport System V/386 3.0e.

When NBUF is set back to 400K on a 4Meg system, with three xterms running
/bin/sh, and some spawned getty's sar -r reports:
19:40:01	149	15072 (out of 16800 swap space blocks)

Running GNU Emacs 18.52 and DOSMerge 386 1.1U at the same time results in
swapping when you move the mouse from one window to the other. Often emacs
will sit there for several seconds before responding to keyboard commands.

8 meg is looking REAL attractive as the memory size to go with. Especially since
X11 is rumored to be a real porker on all systems supporting it so far.

Looking for:
	xterm converted to simulate being a "scan-code" terminal.
	Where to post WGE X10R4 toys (GIF/IFF -> X5 bitmap convertors etc...)
	Online System V/386 man pages. :)

Scott Turner
scotty at l5comp -or- uunet!l5comp!scotty