Why use U* over VMS
Olli-Matti Penttinen
pena at fuug.fi
Fri Nov 2 02:48:30 AEST 1990
In article <3749 at idunno.Princeton.EDU> rhl at astro.Princeton.EDU (Robert Lupton (the Good)) writes:
>Before you all move over to VMS, happy in the knowledge that it supports
>stream linefeed (unix-style) files, beware that the C rtl implementation
>of read/write/open/close that works with them is glacially slow. Too slow
>to be used (at least for the sort of image processing that I was doing).
The best thing about RMS is it's ability to support DBMS's which
generally run circles 'round a similar one under Ultrix/BSD. Besides,
it's a little bit simpler to implement a database using a filesystem
w/ built in ISAM instead of opening a Unix partition and seeking here
and there.
The worst thing is that (at least under VMS 4.x) you really had to
know the exact file type of a *TEXT FILE* to be able to do anything
usefull with it. For example: you could not fseek into the middle of
a line (i.e. record) of a variable-lenght-record file, or
whatchamacallit, which happens to be the default for all FORTRAN and
EDIT output. You had to convert it to stream type before processing.
One other point: when was the last you looked at the source of
MicroEmacs? I'm not saying that it's optimally (or even sensibly)
coded for each OS, but it sure strikes odd to find all that VMS only
code in it.
MicroEmacs 3.10:
ibmpc.c: 11928 bytes
os2.c: 11389 bytes
unix.c: 14470 bytes
vms.c: 32526 bytes
Unfortunately (for VMS), there even are missing features ...
==pena
--
Olli-Matti Penttinen <pena at fuug.innopoli.fi>
Brainware Oy "When in doubt, use brute force."
Tekniikantie 17 --Ken Thompson
02150 ESPOO, Finland Tel. +358 0 4375 320 Fax. +358 0 4553 117
More information about the Comp.unix.programmer
mailing list