dave@micropen (David F. Carlson) (03/25/89)
This is in reference to a recent flame from John Sully's account. (John, if you lend out your account again make sure the "flamer" refrains from scatological material that devalues this news group. Such postings do none of us any good!) To answer the poster, the thought of a bastardized SIII/S7/usoft-kluge *did* make me choose to support standard AT&T UNIX, no doubt about it. But as to Microport's owning sole keys to the kingdom--I doubt it! Since the advent of UNIX SV/386 r3.2, Xenix is now AT&T standard and Microport is less than up to date. So, given my already stated goal of staying on the AT&T course, going to r 3.2 soon is a probability. Why not? (I'm glad I'm not a XENIX developer needing to do a mega-port back to AT&T and I thank Microport for being AT&T up to the recent AT&T SV/386 R3.2.) As to helping Microport, yes, their phone reps take lots of sh*t they don't deserve: AT&T bugs in the SV 386 r3.0 code they ported from are numerous and potentially showstopping. However, Microport took a market strategy that I never quite understood. The bulk of their customers are hackers and a smattering of professional developers (like myself). We are a rare technical breed that don't mind working hard to get the job done if tools are present to do the job. Source code to "simple" Microport programs should have always been available for customization. Source code for Microport device drivers should have been easily available for modification since Microport obviously didn't have the man-power to do it themselves. This would encourage developers and hacker to contribute to the driver collection (like Mark deGroots excellent tone generator which I use daily.) This could have been a hackers paradise: UNIX and USENET and tons of free software to play with! Support would be better since all mods would be tested on many machines and all released back to the author. For Microport, thin engineering budgets would be eased by claiming AS-IS basis on everything except AT&T code (which would be fixed by AT&T "in the next release...") I believe many of us where disappointed to find simple bugs (like everex tape driver crashes or floppy disk multiple access hangs) that would take 5 minutes to fix (and post diffs!) but were never attended to because Microport wanted to support RLL drives or the IBM PS/80 or some other limited utility foolishness. Perhaps I am still clinging to the open nature of CP/M and other hacker environments like BSD/UNIX several years ago when *everyone* had source. But I truly believe a market niche exists for such a product. The other weak spot for me with Microport is as a developer I *need* certain material concerning the UNIX kernel. The kernel debugger is useless without any doc. Ditto adb(1M). Certain questions about kernel interrupt structure I have found no answers for in a year of trying. (Why do external interrupts have at times *very* large latencies? Why do lower level interrupts, ie lower than the clock tick, have the potential to stop callout table procedures from running for several clock periods?) This is what I *need* for support to get my job done. Microport has my gratitude and would (will) have my support if I can get my job done in a professional and efficient manner. Otherwise, no dice. -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
nvk@ddsw1.MCS.COM (Norman Kohn) (03/26/89)
In article <661@micropen> dave@micropen (David F. Carlson) writes: >As to helping Microport, yes, their phone reps take lots of sh*t they don't >deserve: AT&T bugs in the SV 386 r3.0 code they ported from are numerous >and potentially showstopping. However, Microport took a market strategy that >I never quite understood. The bulk of their customers are hackers and a >smattering of professional developers (like myself). The economics of supporting an enterprise like Microport must be daunting. I remember having similar concerns about Aztec, before its expansion to MSDOS (and my move to SVAT, so I could have a more standard environment and dispense with overlays). Every sale creates a potential support obligation for the indefinite future, and without cumbersome accounting the cost of the support (yes, it costs $$ to have someone intelligent sit by the phone) must be borne by future sales. A successful software house is thus a sort of ponzi scheme, in which sales must grow exponentially if support staff are to be paid out of current revenues. I stuck with uport because, others' complaints to the contrary, it has been the only vendor of a large, complex software system with truly available technical people. No, they couldn't resolve all apparent software butgs... but in a system as large and complex as unix, running on various hardware configurations, that's not a surprise. (I still haven't dared try again to add swap space on a second hard drive...) >I believe many of us where disappointed to find simple bugs (like everex tape >driver crashes or floppy disk multiple access hangs) that would take 5 minutes >to fix (and post diffs!) but were never attended to ... Tape support was less of a problem, of course, back in the days when Bell didn't fancy itself a software competitor. Yet Bell's technical staff is so protected you'll resolve to change vendors if you ever try to reach them. Even the sales staff are hard to reach, except by appointment. Think about it, though. Releasing source might well have been a better strategy. Yet it would have been bound to trigger support calls from people who'd messed up the driver, or forgotten that they'd tinkered with it. And the source might contain proprietary code that uport isn't licensed to release. >because Microport wanted to support RLL drives... Ah, but you should see how SV386 flies with RLL! Are other versions really any more solid? (My pet bug: Bell XTC tape driver seems to crash the kernel randomly during a tape backup shell script. Happens about 25% of the time, only since upgrade to 3.0e (386) and subsequently adding RLL, 2nd hard drive, and 2nd Digiboard. I don't see how I'll ever find the problem, but maybe it'll disappear the way it came. Only happens with tape access, so it's unlikely to be in uport's lap. Bell, as usual, piously asserts "we don't support uport" and smirks... For SV386 I suppose that there's always the option of purchasing kernel and runtime licenses from Interactive and using the remainder of the 386 port from uport. gcc, which runs nicely under uport, is probably the compiler of choice. For controlling support costs and maintaining availability, how about making the uport bbs into something useful? Its present form is primitive, and there's no practical way to search for discussion of specific problems. The tech support staff must spend its days reinventing the wheel. (At one time, uport reportedly had the policy of starting all new programmers in tech support... a reasonable way to break in programmers, but also a guarantee of green staff on the other end of the line.) -- Norman Kohn | ...ddsw1!nvk!norman Chicago, Il. | days/ans svc: (312) 650-6840 | eves: (312) 373-0564
caf@omen.UUCP (Chuck Forsberg WA7KGX) (03/27/89)
In article <661@micropen> dave@micropen (David F. Carlson) writes:
:going to r 3.2 soon is a probability. Why not? (I'm glad I'm not a XENIX
:developer needing to do a mega-port back to AT&T and I thank Microport for
:being AT&T up to the recent AT&T SV/386 R3.2.)
All this Xenix!=Unix flamage has finally lit my afterburner.
First off, methinks most of the Xenix!=Unix urban legend is
the result of 8086 and 286 limitations. Unix and 64k segments
are not totally miscible.
As far as Xenix developers "porting back to Unix", I can
relate my experiences porting Xenix Professional-YAM "back to"
Unix, primarily Microport 286 and Interactive's 386/ix.
The first problem is that *nix Pro-YAM no longer fits in small
model, certainly not with the Microport compiler.
Unfortunately, some modules cause an internal error on the
Microport compiler when I attempted to use the large model.
Oh well, the 386 box works OK for duplicating diskettes.
For Interactive's Unix, several changes had to be made.
First off I had to get rid off the last few null pointer
dereferences, these caused core dumps. That also makes
compiling on SunOS possible.
Then 386/ix uses HDB UUCP, whose locking mechanism differs
slightly from that used by Classic UUCP, BSD UUCP, and SCO's
HDB UUCP. Which if any of these is the *real Unix* I haven't
the slightest idea.
Another major porting problem is the keyboard handling of fnx
and alt keys. By default Xenix gives a dozen or so fnx keys,
but there's room in the tables to define all the alt keys and
more fnx codes. 386/ix defaults to a code for each alt key
and some fnx keys and my doco doesn't indicate any way to
define any more. My keyboard decoder is starting to look like
a Teletype stunt box.
Finally there is this matter of installation. Xenix
Professional-YAM uses the "install" command that reads a tar
file and then executes a shell script in the /once directory.
386/ix prefers to mount the diskette and then start executing
a program therein. Of course 386/ix is easier to set up
because there are no 286 users to support.
Another difference related to the timing of short intervals.
Xenix has the nap call with a resolution of about 20
milliseconds. The closest thing for !Xenix is the poll call,
but there may be more Unix systems out there that support nap
than poll so far. It's a shame the keyboard and tty lines
aren't "streams devices".
I'd love to use the BSD style select call available in recent
versions of Xenix. Unfortunately, 386/ix doesn't have that,
and Pro-YAM needs redesign to take advantage of select. So,
no select. Maybe it's part of SVr5.
Meanwhile, I have some programs compiled in 1985 still running
on Xenix 386 2.3.3 using a 600 MB "big fat scuzzy Wren V".
Sure is nice not to have netnews blow out the freelist already.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAFstever@tree.UUCP (Steve Rudek) (03/28/89)
In article <661@micropen>, dave@micropen (David F. Carlson) writes: > This is in reference to a recent flame from John Sully's account. (John, > if you lend out your account again make sure the "flamer" refrains from > scatological material that devalues this news group. Such postings do none > of us any good!) It wasn't John Sully (John can write) and it wasn't even from Microport (weren't you skeptical enough to take a look at the expanded header?). > to do the job. Source code to "simple" Microport programs should have always > been available for customization. Source code for Microport device drivers > should have been easily available for modification since Microport obviously > didn't have the man-power to do it themselves. This would encourage developers I don't really expect this to come to pass, but it would be nice if at least NOW microport would release this source. IT WOULD ALSO BE SMART. If anyone from Microport is reading this, consider: if the company folds that source isn't going to do *anyone* any good -- and a lot of customers are going to be abandoned with *still* broken products (the 2.4 driver is still causing double panics on at least some machines) and no hope of ever getting a stable UNIX. On the other hand, if the company really does have a fighting chance of staying alive the odds would be considerably improved by releasing the code because (1) it would generate customer good will and good will means repeat business and recommendations (2) it would give both current and potential new users hope that the the really awful bugs might actually be fixed someday. I don't know what is left of Microport -- does *anyone* know of a way to get this message to the right people? I saw the earlier posting from Microport Admin re: DOS Merge 2.0 for $60. I would be *delighted* to buy the product if my serial ports weren't so flaky. As things stand, I never know when this system (running the latest release -- V/AT 2.4) will crash; given that kind of uncertainty, wouldn't it be silly for me to push my luck by also trying to run a concurrent DOS process? ------------- P.S.> I don't suppose Microport is still running a BBS?
dave@micropen (David F. Carlson) (03/29/89)
In article <743@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: > In article <661@micropen> dave@micropen (David F. Carlson) writes: > :going to r 3.2 soon is a probability. Why not? (I'm glad I'm not a XENIX > :developer needing to do a mega-port back to AT&T and I thank Microport for > :being AT&T up to the recent AT&T SV/386 R3.2.) > > All this Xenix!=Unix flamage has finally lit my afterburner. > > First off, methinks most of the Xenix!=Unix urban legend is > the result of 8086 and 286 limitations. Unix and 64k segments > are not totally miscible. > > As far as Xenix developers "porting back to Unix", I can > relate my experiences porting Xenix Professional-YAM "back to" > Unix, primarily Microport 286 and Interactive's 386/ix. > > Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf > Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ > Omen Technology Inc "The High Reliability Software" I am glad Chuck, as the author of a complex program, decided to post. Maybe we might even have a flame free, open debate here (for a change!) Many of the problems he mentions are UUCP, which for a comm program are, important. NULL pointer problems, (I *am* suprised: doesn't Xenix have lint(1) :-)!), and other 64K compiler stuff will always cause port hassles. My point was more like my terminfo code, which the Xenix /etc/ttys and termcap filched from who knows what version, will be a dog to port. Worse than from straight BSD that I took much of my low-level stuff from. Terminfo offers sanity in that everything is in one place rather than strung out over 159 different ioctls (which arg does TIOCLBIS take anyway?) What a mess. Curses programs using older versions will require substantial mods to run under SVr3.0 level curses, (which although lacking color is the best curses I've seen yet.) As you state, UUCP and any code which requires cooperative file locking will be a pain. Any code that requires record locking to maintain consistancy you'd be nuts to write to an "orphan" UNIX (XENIX). Writing device drivers (as I often do) in a basterdized (SIII+V7+usoft-kruft+SCO-kruft+...) environment must be less than fun. Getting good doc for kernel hacking from a "business-oriented" vendor is always fun anyway. (Not that my vendor is stellar in this regard.) AT&T sucks for not having a sub-second clock interval. Although XENIX nap() is anemnic compared to BSD ftime(). Nice debate. I'll stick with AT&T for the time being (until a nicer POSIX kernel is standard!) -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
hsu@kampi.hut.fi (Heikki Suonsivu) (03/29/89)
In article <743@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes: >First off I had to get rid off the last few null pointer >dereferences, these caused core dumps. That also makes To my opinion and expreience, null pointers dereferences causing segmentation fault etc helps a lot to catch some nasty bugs. True that lots of software do it nasty way but I helps if one really wants portability (I also need to port my stuff even down to mesh-dosh). >slightly from that used by Classic UUCP, BSD UUCP, and SCO's >HDB UUCP. Which if any of these is the *real Unix* I haven't HDB on all system V r3:s I have used has 10-char+\n locks in /usr/spool/locks. HDB though isn't too smart about obeying them. I like /usr/spool/locks style better, though it requires some work sometimes when installing older software. >Xenix has the nap call with a resolution of about 20 I saw nap posted in some sources group. It was simple though requiring kernel relink as it uses a driver which calls kernel routine which can use better resolution, and had library routine nap which just opened that devide. I lost that file so I can't tell what was the call (If someone has it I would like to get it back :-).
tvf@cci632.UUCP (Tom Frauenhofer) (03/29/89)
In article <252@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >P.S.> I don't suppose Microport is still running a BBS? Yes, I logged on to it last monday (3/27/89). My only beef with their BBS is that every few months I seem to have to re-register. Is the BBS they're using so flaky it swallows the user follow all the time? Or is it just mismanaged? Inquiring minds want to know... ( :-) ). Thomas V. Frauenhofer ...!rutgers!rochester!cci632!ccird7!tvf *or* ...!rochester!cci632!ccird7!frau!tvf *or* ...!rochester!rit!anna!ma!tvf1477 BLOOM: You can't shoot the actors! They're human beings! BIALYSTOCK: Oh Yeah? You ever eat with one?
caf@omen.UUCP (Chuck Forsberg WA7KGX) (03/30/89)
In article <663@micropen> dave@micropen (David F. Carlson) writes:
:I am glad Chuck, as the author of a complex program, decided to post. Maybe
:we might even have a flame free, open debate here (for a change!)
:
:Many of the problems he mentions are UUCP, which for a comm program are,
:important. NULL pointer problems, (I *am* suprised: doesn't Xenix have lint(1)
Dereferencing of null pointers is a dynamic problem.
(e.g., if(*s) should be (if s && *s))
If you have a lint that catches that, send me a copy!
Come to think of it, it would be nice to see some
functionality (more sensitive checking) improvements
in lint since V7, instead of changes to the user
interface that break other programs.
::-)!), and other 64K compiler stuff will always cause port hassles.
:
:My point was more like my terminfo code, which the Xenix /etc/ttys and termcap
Terminfo does uses neither /etc/termcap or /etc/ttys
:filched from who knows what version, will be a dog to port. Worse than from
:straight BSD that I took much of my low-level stuff from. Terminfo offers
:sanity in that everything is in one place rather than strung out over 159
:different ioctls (which arg does TIOCLBIS take anyway?) What a mess.
TIOCLBIS is part of BSD, and does not appear in either
Xenix or Unix/386 3.2.
:
:Curses programs using older versions will require substantial mods to run
:under SVr3.0 level curses, (which although lacking color is the best curses
:I've seen yet.)
That was true of Xenix also, alas.
:
:As you state, UUCP and any code which requires cooperative file locking will
:be a pain. Any code that requires record locking to maintain consistancy you'd
:be nuts to write to an "orphan" UNIX (XENIX).
:
:Writing device drivers (as I often do) in a basterdized
:(SIII+V7+usoft-kruft+SCO-kruft+...) environment must be less than fun. Getting
Talk to the poor lhackers (as in "lusers") trying to
get Unix rz/sz to work properly under AIX...
:good doc for kernel hacking from a "business-oriented" vendor is always fun
:anyway. (Not that my vendor is stellar in this regard.)
Funny you should mention. My Bell Technologies "Blit"
package won't install on Unix/386 3.2, there is a
FLAG DAY. When I installed the files manually I
discovered that the format for driver modules had
changed completely. Since the change from Unix/386
3.0 to 3.2 has in less than a year rendered my high
resolution X windows system usless, I can't imagine
how the change from Xenix could be worse. BTW, my
Kimtron 4-port board doesn't work with Unix/386 3.2.
:
:AT&T sucks for not having a sub-second clock interval. Although XENIX nap()
:is anemnic compared to BSD ftime().
Xenix has ftime(), but ftime is not a substitute for nap()
if you want to give up the CPU for a subsecond interval.
Xenix also has select() which I haven't used because it
isn't in Unix (yet).
:
:Nice debate. I'll stick with AT&T for the time being (until a nicer POSIX
:kernel is standard!)
Hmmm... a nicer Posix standard... great idea. For
openers, How about a dial-out program being able to
check carrier detect (on the dial-out line, not the
controlling terminal) efficiently?
"Keep those cards and letters coming."
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAFchip@ateng.ateng.com (Chip Salzenberg) (03/30/89)
I agree with David Carlson that we need to keep *calm* when discussing Xenix vs. SysV. Now, on to the discussion, which is already in progress. According to dave@micropen (David F. Carlson): >My point was more like my terminfo code, which the Xenix /etc/ttys and termcap >filched from who knows what version, will be a dog to port. Worse than from >straight BSD that I took much of my low-level stuff from. Terminfo offers >sanity in that everything is in one place rather than strung out over 159 >different ioctls (which arg does TIOCLBIS take anyway?) What a mess. To clear up a few misconception, let me state that SCO Xenix: Includes terminfo, if you want it; Includes termcap, if you want it; Includes V7-ish curses, using termcap; Includes SysV curses, using terminfo; Uses SysV-conformant termio ioctls for tty control. The arguments about terminfo vs. termcap have *nothing* to do with the version of terminal control offered by the kernel. You could put terminfo on BSD ioctls, and you could put termcap on SysV ioctls (as SCO did). >AT&T sucks for not having a sub-second clock interval. Although XENIX nap() >is anemnic compared to BSD ftime(). Which, of course, means that SysV missed the boat. Except for SysV R3.2, which of course includes nap(). -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
friedl@vsi.COM (Stephen J. Friedl) (03/31/89)
In article <252@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes: > > If anyone from Microport is reading this, consider: if the company folds that > source isn't going to do *anyone* any good -- and a lot of customers are going > to be abandoned with *still* broken products (the 2.4 driver is still > causing double panics on at least some machines) and no hope of ever > getting a stable UNIX. They would be foolish to give away an asset that could be sold and the proceeds of which used to pay creditors. It's quite possible that some company (related to the current uport or not) may want to pick up the support work, and they would probably value the source muchly. What a fantasy. *chuckle* Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "I do everything in software, even DMA" - Gary W. Keefe (garyk@telxon)