From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: AT&T Long Distance Boycott (was: BNR2SS, Mach, and The Lawsuit)
Organization: Novell NPD -- Sandy, UT
Date: Tue, 8 Sep 1992 16:46:22 GMT

In article <1992Sep08.085437.419@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
>In article <QA2J6LM@taronga.com> peter@taronga.com (Peter da Silva) writes:
>>Sorry, if you have to provide your own termcap you're back where you started:
>
>Sorry, if you have to provide your own main() your language is useless.
>
>Sorry, if you have to provide your own fp-to-base-37 routines your language
>is useless.
>
>Sorry, if you have to provide your own custom IO routines, your language is
>useless.
>
>Etc.
>
>The termcap library is *SMALL*.  It's better if it's on every system, but
>it's small enough that it can be provided as part of your application and
>not be terribly visible.  Emacs does that, or did at one point (although
>emacs is not something I like using as an example).

	What about the termcap file itself?  Lat time I checked, the one on
my ELC was 133K.  The one on icarus (a SPARCServer 2) is *much* larger.
This is probably a nit, since everyone knows that most Digital Supplied
utilities won't work with anything but VT series terminals anyway.  Besides,
VMS has it's own termcap-incompatable terminal specification language that
it's editors ignore.

	One standard I think is important for most applications that are
moderately screen oriented is an ISO Curses library.  VMS Curses is not ISO
compliant (ie: it has a different idea of default touching of windows and
stacking write-through).  Of course you could always #ifdef your code to use
SMG services after you rewrite it's expectations.

	VMS doesn't support the concept of SUID/SGID necessary from most
things, like score files in games.  Instead, you have to install the image
with priveledges (ie: I can't make an SUID "terry" program; only an SUID
SYSTEM with some priveledges).

	The total lack of a CBREAK mode disallows single character I/O,
unless you are willing to call SYS$QIO() directly.  Raw mode requires a
QIO with IO$_SENSEMODE/IO$_SETMODE.

	Try porting "robots" (I don't have to; I have an implementation in
VAX COBOL) and see what POSIX buys you.

	Try the following:

	o	Open a file created with a text editor (this will insure
		it is a variable length record file with implied carriage
		return carriage control).
	o	Read a line up to and including the EOL.
	o	save the tell() value.
	o	lseek() to the tell location.
	o	Suprise!  You're back at the start of the file!  The seek
		pointer is a record rather than a byte offset, and the
		pointer (in nonconformance with POSIX) isn't advanced
		after the EOL is faked up at the record end, like it
		should be, but you are required to actually read the
		firt character of the next "record".
	o	For extra points (now that you realise that you have to keep
		a record pointer and an offset-into-record pointer) write a
		disk-based interpreter (BASIC or tch or bash, etc.).  Hint:
		ungetc(getc()) before an ftell() will tie you to standard
		I/O, but will advance the pointer as required).

	POSIX "compliance" is a check-off for government contracts, since
the government is not allowed to say "UNIX" and make it stick any more (you
should know this; you were with SCO during the bidding for the AFCAC 451 and
Desktop III contracts that caused it to adopt SVR3).

>3.  As for mail, tell you what, Peter:  why don't you come up with a mail
>system (reader, sender, interface, system-to-system interface, file format,
>filesystem layout, etc.) that can work on all systems, and then I'll add the
>code to t?rn to support that.

	MMDF (Multi-Memorandum Distribution Facility) ... OK, it stinks, but
it's what you asked for.

	Look, POSIX buys you a lot of things (including the ability to deny
that the MS-DOS file system is POSIX compliant when mounted read-write but
is when it's mounted read only. }8-)).  It doesn't buy you a compatability
platform for most applications, especially modern ones (like xterm).  Even
games take a lot of work, and they're not "real" (I spent about 12 hours
getting cbzone to run under VMS).

	Peter's right; POSIX is a step along the road, but it isn't a
platform (*or a system*).


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.
Newsgroups: comp.unix.bsd