info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Georgia Tech Software Tools for Primos
174 views
Skip to first unread message
Edward Feustel
Nov 30, 2012, 9:47:50 AM11/30/12
to
Does anyone happen to have a source tape, disk, or listing of
the source of Software Tools? Unfortunately, I had to leave
them behind when I left Prime. They were well integrated into
Primos and provided a better toolkit than Primix for me.
TIA,
Ed Feustel
the source of Software Tools? Unfortunately, I had to leave
them behind when I left Prime. They were well integrated into
Primos and provided a better toolkit than Primix for me.
TIA,
Ed Feustel
Al Kossow
Nov 30, 2012, 12:28:56 PM11/30/12
to
On 11/30/12 6:47 AM, Edward Feustel wrote:
> Does anyone happen to have a source tape, disk, or listing of
> the source of Software Tools?
Bill Gunshannon and I have been looking for this for a long time.
> Does anyone happen to have a source tape, disk, or listing of
> the source of Software Tools?
It appears that no one saved a copy.
Daiyu Hurst
Dec 1, 2012, 1:11:15 AM12/1/12
to
Technology I was corresponding with
(it's in my email archives and will take some time to find), but he
claimed he still had them. It
may have been Gene Spafford; see below.
Meanwhile some other names associated with it, maybe tracking them
down might help:
Peter Salus (USENIX historian) had a copy of the User's Guide as
recently as 2000:
http://static.usenix.org/publications/login/2000-2/20yrsago.html
[the user's guide:
Software Tools Subsystem User's Guide
T. Allen Akin, Perry Flinn, and Dan Forsythe
George Institute of Technology
]
Eugene H. Spafford [sp...@purdue.edu] was a co-author of the tools
package
Resume at http://spaf.cerias.purdue.edu/pers/vita.pdf
They had the tools at Chilton in the UK:
http://www.chilton-computing.org.uk/acd/literature/annual_reports/p007.htm
All kinds of stuff keeps turning up that was long thought lost. Have
hope!
Daiyu Hurst
Dec 2, 2012, 1:54:45 PM12/2/12
to
On Dec 1, 1:11 am, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
>
> > On 11/30/12 6:47 AM, Edward Feustel wrote:
>
> > > Does anyone happen to have a source tape, disk, or listing of
> > > the source of Software Tools?
>
> > Bill Gunshannon and I have been looking for this for a long time.
> > It appears that no one saved a copy.
>
> I can't remember the name of the guy at Georgia Institute of
> Technology I was corresponding with
> (it's in my email archives and will take some time to find), but he
> claimed he still had them. It
> may have been Gene Spafford; see below.
>
> Meanwhile some other names associated with it, maybe tracking them
> down might help:
>
> Peter Salus (USENIX historian) had a copy of the User's Guide as
> recently as 2000:
>
> http://static.usenix.org/publications/login/2000-2/20yrsago.html
>
> [the user's guide:
> Software Tools Subsystem User's Guide
> T. Allen Akin, Perry Flinn, and Dan Forsythe
> George Institute of Technology
> ]
>
> Eugene H. Spafford [s...@purdue.edu] was a co-author of the tools
> On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
>
> > On 11/30/12 6:47 AM, Edward Feustel wrote:
>
> > > Does anyone happen to have a source tape, disk, or listing of
> > > the source of Software Tools?
>
> > Bill Gunshannon and I have been looking for this for a long time.
> > It appears that no one saved a copy.
>
> I can't remember the name of the guy at Georgia Institute of
> Technology I was corresponding with
> (it's in my email archives and will take some time to find), but he
> claimed he still had them. It
> may have been Gene Spafford; see below.
>
> Meanwhile some other names associated with it, maybe tracking them
> down might help:
>
> Peter Salus (USENIX historian) had a copy of the User's Guide as
> recently as 2000:
>
> http://static.usenix.org/publications/login/2000-2/20yrsago.html
>
> [the user's guide:
> Software Tools Subsystem User's Guide
> T. Allen Akin, Perry Flinn, and Dan Forsythe
> George Institute of Technology
> ]
>
> package
> Resume athttp://spaf.cerias.purdue.edu/pers/vita.pdf
>
> They had the tools at Chilton in the UK:
>
> http://www.chilton-computing.org.uk/acd/literature/annual_reports/p00...
> They had the tools at Chilton in the UK:
>
>
> All kinds of stuff keeps turning up that was long thought lost. Have
> hope!
Ok, correction, Phil Enslow at Georgia Institute of Technology, was
> All kinds of stuff keeps turning up that was long thought lost. Have
> hope!
who I
was corresponding with.
-dai
Daiyu Hurst
Dec 13, 2012, 6:01:18 PM12/13/12
to
On Dec 2, 1:54 pm, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> On Dec 1, 1:11 am, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> > On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
> > > On 11/30/12 6:47 AM, Edward Feustel wrote:
>
> > > > Does anyone happen to have a source tape, disk, or listing of
> > > > the source of Software Tools?
>
> > > Bill Gunshannon and I have been looking for this for a long time.
> > > It appears that no one saved a copy.
Folks, does this look like the Holy Grail of which we speak? I got
> On Dec 1, 1:11 am, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> > On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
> > > On 11/30/12 6:47 AM, Edward Feustel wrote:
>
> > > > Does anyone happen to have a source tape, disk, or listing of
> > > > the source of Software Tools?
>
> > > Bill Gunshannon and I have been looking for this for a long time.
> > > It appears that no one saved a copy.
this
from a member of my Control Data group; it appears to be the portable
distribution, un-ported.
TABLE OF CONTENTS
Part 1
Summary of Tools and Library Routines
Introduction
File 2 - Copy (in Fortran)
File 3 - Ratfor bootstrap (in Fortran)
File 4 - Library Routines, Symbol Definitions, and
Temporary Versions of the Primitives
File 5 - Reading Command Line Arguments - Echo and Getarg
File 6 - The CAT tool for testing File Access Primitives
File 7 - File Insertion - Incl
File 8 - Ratfor in ratfor
------ - In-Core Editing.
File 9 - Text Formatting
File 10 - File Archiving
File 11 - Text Editing - Random IO Primitives
File 12 - The Remainder of the Basic Tools
File 13 - The Shell
File 14 - Documentation
File 15 - Additional Tools (which have been included as
they were received; some may require additional
primitives)
File 16 - Spelling Dictionary
Part 2
Specifications for System-dependent Primitives
SUMMARY OF CONTENTS OF TAPE
1. TOOLS
ar ................................. archive file maintainer
cat ....................... concatenate and print text files
ch .................................... change text patterns
comm ....................... print lines common to two files
cpress ................................ compress input files
crt ..................................copy files to terminal
crypt ................... encrypt and decrypt standard input
date ............................... print the date and time
dc ......................................... desk calculator
detab ............................... convert tabs to spaces
diff ..................... isolate differences between files
echo ........................... echo command line arguments
ed .................................................. editor
edin ........................................ in-core editor
entab .................... convert spaces to tabs and spaces
expand .............................. uncompress input files
fb ................ search blocks of lines for text patterns
field ............................ manipulate fields of data
find ....................... search a file for text patterns
format ......................................... format text
includ ......................... file inclusion preprocessor
kwic ............ prepare lines for keyword-in-context index
lam ......................................... laminate files
ll ...................................... print line lengths
macro ...................... general-purpose macro processor
mcol ................................ multicolumn formatting
mv .................................... move (rename) a file
os .................. convert backspaces into multiple lines
pl ................... print specified lines/pages in a file
pr .............................................. print file
ratfor ................................. Ratfor preprocessor
rev .......................................... reverse lines
rm ................................... remove (delete) files
roff ........................................ [see 'format']
sedit ........................................ stream editor
sh ................................ command line interpreter
show ......................... show all characters in a file
sort .......................... sort and/or merge text files
spell ............................... locate spelling errors
split ............................... split file into pieces
tail ............................ print last lines of a file
tee ................... copy input to output and named files
tr ............................... character transliteration
tsort ........................... topologically sort symbols
uniq ............. strip adjacent repeated lines from a file
unrot ...................... unrotate lines prepared by kwic
wc ............. count lines, words, and characters in files
xref ..................... make a cross reference of symbols
-1-
2. SUBROUTINES AND PRIMITIVES
(* indicates that the implementation of the routine is
system-dependent
# indicates that the routine may, in some cases, be
system-dependent)
definitions .................... standard Ratfor definitions
File Manipulation
#amove ......................... move (rename) file1 to file2
*close ................................ close (detach) a file
*create .... create a new file (or overwrite an existing one)
*gettyp .............. get type of file (character or binary)
*isatty .......... determine if file is a teletype/CRT device
#mkuniq ........................... generate unique file name
*open ... open an existing file for reading, writing, or both
*remove .................. remove a file from the file system
I/O
fcopy ............................. copy file in to file out
*flush .................... flush output buffer for file 'fd'
getc .................... read character from standard input
*getch ............................. read character from file
#getlin ............................. get next line from file
*note ....................... determine current file position
#prompt ............................... prompt user for input
putc .................... write character to standard output
*putch .............................. write character to file
putdec .................. write integer n in field width >=w
putint ..... write integer n onto file fd in field width >=w
#putlin ..................... output a line onto a given file
putstr ........... write str onto file fd in field width >=w
*readf ............................. read from an opened file
*remark ........................... print single-line message
*seek ............................... move read/write pointer
*writef ............................. write to an opened file
Process Control
*spawn ...................................... execute subtask
String Manipulation
addset ........... put c in array(j) if it fits, increment j
addstr ...... add string s to str(j) if it fits, increment j
clower ................................ fold c to lower case
concat ...................... concatenate 2 strings together
ctoc ................................. copy string-to-string
ctoi ....... convert string at in(i) to integer, increment i
ctomn ....... translate ascii control character to mnemonic
cupper ..................... convert character to upper case
equal ............ compare str1 to str2; return YES if equal
esc .... map array(i) into escaped character, if appropriate
fold .......................... convert string to lower case
gctoi .......... generalized character-to-integer conversion
getwrd . get non-blank word from in(i) into out, increment i
-2-
gitoc .......... generalized integer-to-character conversion
index ....................... find character c in string str
itoc ................... convert integer to character string
length ............................ compute length of string
lower ......................... convert string to lower case
mntoc ......................... ascii mneumonic to character
scopy ...................... copy string at from(i) to to(j)
sdrop ........................ drop characters from a string
skipbl ...................... skip blanks and tabs at str(i)
stake ........................ take characters from a string
stcopy ........ copy string at from(i) to to(j); increment j
strcmp ................................... compare 2 strings
strim .......... trim trailing blanks and tabs from a string
substr ...................... take a substring from a string
type ........................... determine type of character
upper ......................... convert string to upper case
Pattern Matching
amatch ........ look for pattern matching regular expression
getpat .......encode regular expression for pattern matching
makpat ...... encode regular expression for pattern matching
match ....................... match pattern anywhere on line
Command Line Handling
*delarg ............. delete command line argument number 'n'
*getarg .......................... get command line arguments
gfnarg .......................... get next filename argument
query ...................... print command usage information
Dynamic Storage Allocation
dsfree ..................... free a block of dynamic storage
dsget .................... obtain a block of dynamic storage
dsinit .......................... initialize dynamic storage
Symbol Table Manipulation
delete ................... remove a symbol from symbol table
enter ......................... place symbol in symbol table
lookup ..... get string associated with name from hash table
mktabl ................................. make a symbol table
rmtabl ............................... remove a symbol table
sctabl .................. scan all symbols in a symbol table
Date Manipulation
fmtdat .................... convert date to character string
*getnow ........................... get current date and time
wkday ...... get day-of-week corresponding to month-day-year
Error Handling
cant ...... print 'name: can't open' and terminate execution
error .... print single-line message and terminate execution
Miscellaneous
*endst . close all open files and terminate program execution
*initst .. initialize all standard files and common variables
-3-
3. ADDITIONAL TOOLS AND LIBRARY ROUTINES
As assortment of tools and library routines including:
1) Alternate versions of tools included earlier on
the tape
2) Tools requiring additional primitives
3) Experimental tools and routines
4) Other tools and routines not yet accepted as part
of the basic package
4. COMPLETE DOCUMENTATION FOR TOOLS AND LIBRARY ROUTINES
5. PRIMERS
edit ................................................ editor
ratfor ................................. ratfor preprocessor
6. SPELLING DICTIONARY
Daiyu Hurst
Dec 13, 2012, 6:03:19 PM12/13/12
to
On Dec 13, 6:01 pm, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> On Dec 2, 1:54 pm, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
>
> > On Dec 1, 1:11 am, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> > > On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
> > > > On 11/30/12 6:47 AM, Edward Feustel wrote:
>
> > > > > Does anyone happen to have a source tape, disk, or listing of
> > > > > the source of Software Tools?
>
> > > > Bill Gunshannon and I have been looking for this for a long time.
> > > > It appears that no one saved a copy.
>
> Folks, does this look like the Holy Grail of which we speak? I got this
> from a member of my Control Data group; it appears to be the portable
> distribution, un-ported.
>
Assuming so, have at it:
> On Dec 2, 1:54 pm, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
>
> > On Dec 1, 1:11 am, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> > > On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
> > > > On 11/30/12 6:47 AM, Edward Feustel wrote:
>
> > > > > Does anyone happen to have a source tape, disk, or listing of
> > > > > the source of Software Tools?
>
> > > > Bill Gunshannon and I have been looking for this for a long time.
> > > > It appears that no one saved a copy.
>
> Folks, does this look like the Holy Grail of which we speak? I got this
> from a member of my Control Data group; it appears to be the portable
> distribution, un-ported.
>
https://docs.google.com/open?id=0ByJs3HoO8aRVd1JlOGJWRlJhTDg
-dai
Bill Gunshannon
Dec 13, 2012, 6:14:30 PM12/13/12
to
In article <655bf127-e26a-4265...@f8g2000yqa.googlegroups.com>,
I don't know if it is the holy grail but I would love to have a copy
of it. Value probably depends on how early a version it is. There
was a lot of work done by the Users Group over the years it was in
use.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
of it. Value probably depends on how early a version it is. There
was a lot of work done by the Users Group over the years it was in
use.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Al Kossow
Dec 13, 2012, 7:11:07 PM12/13/12
to
On 12/13/12 3:01 PM, Daiyu Hurst wrote:
> On Dec 2, 1:54 pm, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
>> On Dec 1, 1:11 am, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
>>> On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
>>>> On 11/30/12 6:47 AM, Edward Feustel wrote:
>>
>>>>> Does anyone happen to have a source tape, disk, or listing of
>>>>> the source of Software Tools?
>>
>>>> Bill Gunshannon and I have been looking for this for a long time.
>>>> It appears that no one saved a copy.
>
> Folks, does this look like the Holy Grail of which we speak? I got
> this
> from a member of my Control Data group; it appears to be the portable
> distribution, un-ported.
>
I think the version Ed is looking for the the Georgia Tech version.
> On Dec 2, 1:54 pm, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
>> On Dec 1, 1:11 am, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
>>> On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
>>>> On 11/30/12 6:47 AM, Edward Feustel wrote:
>>
>>>>> Does anyone happen to have a source tape, disk, or listing of
>>>>> the source of Software Tools?
>>
>>>> Bill Gunshannon and I have been looking for this for a long time.
>>>> It appears that no one saved a copy.
>
> Folks, does this look like the Holy Grail of which we speak? I got
> this
> from a member of my Control Data group; it appears to be the portable
> distribution, un-ported.
>
Document scans are up under
http://bitsavers.org/pdf/georgiaTech
Daiyu Hurst
Dec 13, 2012, 8:19:00 PM12/13/12
to
On Dec 13, 6:14 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> In article <655bf127-e26a-4265-8e3a-5f142b456...@f8g2000yqa.googlegroups.com>,
distro from Livermore, you are free to download it from here:
https://docs.google.com/open?id=0ByJs3HoO8aRVd1JlOGJWRlJhTDg
There is also the RSX-11 port, two versions, one from 1981 and
one from 1983, that you can download from one of the DEC archives.
-dai
-dai
> In article <655bf127-e26a-4265-8e3a-5f142b456...@f8g2000yqa.googlegroups.com>,
> Daiyu Hurst <daiyu.hu...@gmail.com> writes:
>
> > On Dec 2, 1:54 pm, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> >> On Dec 1, 1:11 am, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> >> > On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
> >> > > On 11/30/12 6:47 AM, Edward Feustel wrote:
>
> >> > > > Does anyone happen to have a source tape, disk, or listing of
> >> > > > the source of Software Tools?
>
> >> > > Bill Gunshannon and I have been looking for this for a long time.
> >> > > It appears that no one saved a copy.
> > Folks, does this look like the Holy Grail of which we speak? I got this
> > from a member of my Control Data group; it appears to be the portable
> > distribution, un-ported.
>
>
> > On Dec 2, 1:54 pm, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> >> On Dec 1, 1:11 am, Daiyu Hurst <daiyu.hu...@gmail.com> wrote:
> >> > On Nov 30, 12:28 pm, Al Kossow <a...@bitsavers.org> wrote:
> >> > > On 11/30/12 6:47 AM, Edward Feustel wrote:
>
> >> > > > Does anyone happen to have a source tape, disk, or listing of
> >> > > > the source of Software Tools?
>
> >> > > Bill Gunshannon and I have been looking for this for a long time.
> >> > > It appears that no one saved a copy.
> > Folks, does this look like the Holy Grail of which we speak? I got this
> > from a member of my Control Data group; it appears to be the portable
> > distribution, un-ported.
>
> I don't know if it is the holy grail but I would love to have a copy
> of it. Value probably depends on how early a version it is. There
> was a lot of work done by the Users Group over the years it was in
> use.
Bearing in mind, this is not the Georgia Tech port, its the original
> of it. Value probably depends on how early a version it is. There
> was a lot of work done by the Users Group over the years it was in
> use.
distro from Livermore, you are free to download it from here:
https://docs.google.com/open?id=0ByJs3HoO8aRVd1JlOGJWRlJhTDg
There is also the RSX-11 port, two versions, one from 1981 and
one from 1983, that you can download from one of the DEC archives.
-dai
-dai
Daiyu Hurst
Dec 13, 2012, 8:22:37 PM12/13/12
to
USB flashkey with them, to ensure they have their own archives
of their work.
But as more and more companies and institutions lock down the
use of personal flashkeys, we'll have to start building our
own Van Eck hacks into sunglasses... hmmm... can Van Eck
hacking be done with LCD flatscreeens?
Dennis Boone
Dec 13, 2012, 8:57:49 PM12/13/12
to
> Folks, does this look like the Holy Grail of which we speak? I got
> this from a member of my Control Data group; it appears to be the
> portable distribution, un-ported.
I'm pretty sure GATech made some enhancements to integrate the
> this from a member of my Control Data group; it appears to be the
> portable distribution, un-ported.
basic STOS with PRIMOS. Here's the User Guide for the GATech
version:
http://yagi.h-net.msu.edu/prime_manuals/GIT-ICS-85-08_Software_Tools_Subsystem_Users_Guide_4ed_May85.pdf
De
Daiyu Hurst
Dec 13, 2012, 11:55:08 PM12/13/12
to
>
> De
I confess...
I'm a computer programmer at heart. Jim's sig line (or the one he
used to use) expresses my feelings very succinctly:
Software First! (Software Lasts!)
Pick the software you want. Then find the hardware that best runs it.
If the hardware doesn't exist, design it and build it.
So I totally fail to comprehend the value of STVOS/Prime, in a way
that I don't fail to comprehend Primix: Primix was a product, it
was meant to make money.
STVOS/Prime, I don't get, because the Prime computer architecture was
designed to run PRIMOS. I'm not saying PRIMOS was perfect; its Multics
inheritance was perhaps one of its flaws.
Most notably, Joe Osanna's I/O redirection paradigm. Joe was a
Multician, but he created the pipes for Unix, not Multics. The
Multics mechanisms for I/O redirection, like those on the Prime,
as rather clumsy.
That paradigm does not require fork() to be useful; fork() does
enhance it. But Multics and PRIMOS alike would have benefited
from that ONE SINGLE innovation.
OTHERWISE... they were each excellent operating systems, and I
don't get why someone would want to dump a layer of something
else on top of it.
Now, I totally get wanting to find STVOS/Prime from the standpoint
of software archaeology, of wanting to preserve each and every bit
that ever ran on those machines.
But golly gosh, if you want a Unix-like operating system, there
are *dozens* of choices out there.
OTOH, if you want a Multics-like operating system, there are like,
three choices (Multics, PRIMOS, and NOS/VE). Maybe one or two
others.
Ok, I'll stop ranting. Sorry. But one of my long-time favorite
internet ranters is lying on his deathbed, and its got me into
a mess.
Bill Gunshannon
Dec 14, 2012, 7:52:55 AM12/14/12
to
In article <C4Odnaszi4oAGlfN...@giganews.com>,
Everybody in the Users Group made enhancements. :-)
There was also UW-Madison which did the UNIVAC-1100 version. I was at
The US Military Academy during that time and we had a UNIVAC-1100 and
a bunch of Prime-850's (and a couple of smaller Pimess as well, including
one Rabbit.) Being a government site they probably still have copies of
the tapes for both, but jumping thru all the hoops of an FOIA action
to try and get them would likely take until ong after my passing.
There was also UW-Madison which did the UNIVAC-1100 version. I was at
The US Military Academy during that time and we had a UNIVAC-1100 and
a bunch of Prime-850's (and a couple of smaller Pimess as well, including
one Rabbit.) Being a government site they probably still have copies of
the tapes for both, but jumping thru all the hoops of an FOIA action
to try and get them would likely take until ong after my passing.
Bill Gunshannon
Dec 14, 2012, 8:07:01 AM12/14/12
to
In article <badcca16-ee32-499e...@j4g2000yqh.googlegroups.com>,
where this was what happened. Hardware invariably come first. Probably
because it's a lot easier to customize software to fit on the hardware
than the other way around.
> So I totally fail to comprehend the value of STVOS/Prime, in a way
> that I don't fail to comprehend Primix: Primix was a product, it
> was meant to make money.
Having worked with PRIMIX a lot from the very beginning (My printed manuals
are xeroxs of Primes development pages!) I can tell you it was a totally
worthless product. The primary reason for things like PRIMIX and EUNICE
were to open up the world of Unix freeware (yes, we had freeware long before
the Stallman rant) to other OSes. It was all about a common API accross
multiple platforms. Long after STVOS was abandoned and lost all the work
was re-done in the form of POSIX.
> STVOS/Prime, I don't get, because the Prime computer architecture was
> designed to run PRIMOS. I'm not saying PRIMOS was perfect; its Multics
> inheritance was perhaps one of its flaws.
> Most notably, Joe Osanna's I/O redirection paradigm. Joe was a
> Multician, but he created the pipes for Unix, not Multics. The
> Multics mechanisms for I/O redirection, like those on the Prime,
> as rather clumsy.
> That paradigm does not require fork() to be useful; fork() does
> enhance it. But Multics and PRIMOS alike would have benefited
> from that ONE SINGLE innovation.
> OTHERWISE... they were each excellent operating systems, and I
> don't get why someone would want to dump a layer of something
> else on top of it.
See above. it was all about a common API and with the advent of POSIX
it became even more important, especially if you wanted to sell products
to the government.
> Now, I totally get wanting to find STVOS/Prime from the standpoint
> of software archaeology, of wanting to preserve each and every bit
> that ever ran on those machines.
> But golly gosh, if you want a Unix-like operating system, there
> are *dozens* of choices out there.
Except that STVOS was never really an OS. It's an API. Of course, there
was a real, native Unix for Primes but after backing all the work in the
end Prime refused to let the developers release it apparently to protect
the market for their extremely inferior PRIMIX product.
> OTOH, if you want a Multics-like operating system, there are like,
> three choices (Multics, PRIMOS, and NOS/VE). Maybe one or two
> others.
> Ok, I'll stop ranting. Sorry. But one of my long-time favorite
> internet ranters is lying on his deathbed, and its got me into
> a mess.
Nothing wrong with a rant. Especially if it brings out the explanation
for why something was actually done. Reading Debbie Scherrer's original
paper would go a long way towards understanding the goals of the project.
Daiyu Hurst <daiyu...@gmail.com> writes:
> On Dec 13, 8:57 pm, d...@ihatespam.msu.edu (Dennis Boone) wrote:
>> > Folks, does this look like the Holy Grail of which we speak? I got
>> > this from a member of my Control Data group; it appears to be the
>> > portable distribution, un-ported.
>>
>> I'm pretty sure GATech made some enhancements to integrate the
>> basic STOS with PRIMOS. Here's the User Guide for the GATech
>> version:
>>
>> http://yagi.h-net.msu.edu/prime_manuals/GIT-ICS-85-08_Software_Tools_...
>>
>> De
> I confess...
> I'm a computer programmer at heart. Jim's sig line (or the one he
> used to use) expresses my feelings very succinctly:
> Software First! (Software Lasts!)
> Pick the software you want. Then find the hardware that best runs it.
> If the hardware doesn't exist, design it and build it.
With the single exception of The UCSD-Pascal Microengine, name one case
> On Dec 13, 8:57 pm, d...@ihatespam.msu.edu (Dennis Boone) wrote:
>> > Folks, does this look like the Holy Grail of which we speak? I got
>> > this from a member of my Control Data group; it appears to be the
>> > portable distribution, un-ported.
>>
>> I'm pretty sure GATech made some enhancements to integrate the
>> basic STOS with PRIMOS. Here's the User Guide for the GATech
>> version:
>>
>> http://yagi.h-net.msu.edu/prime_manuals/GIT-ICS-85-08_Software_Tools_...
>>
>> De
> I confess...
> I'm a computer programmer at heart. Jim's sig line (or the one he
> used to use) expresses my feelings very succinctly:
> Software First! (Software Lasts!)
> Pick the software you want. Then find the hardware that best runs it.
> If the hardware doesn't exist, design it and build it.
where this was what happened. Hardware invariably come first. Probably
because it's a lot easier to customize software to fit on the hardware
than the other way around.
> So I totally fail to comprehend the value of STVOS/Prime, in a way
> that I don't fail to comprehend Primix: Primix was a product, it
> was meant to make money.
are xeroxs of Primes development pages!) I can tell you it was a totally
worthless product. The primary reason for things like PRIMIX and EUNICE
were to open up the world of Unix freeware (yes, we had freeware long before
the Stallman rant) to other OSes. It was all about a common API accross
multiple platforms. Long after STVOS was abandoned and lost all the work
was re-done in the form of POSIX.
> STVOS/Prime, I don't get, because the Prime computer architecture was
> designed to run PRIMOS. I'm not saying PRIMOS was perfect; its Multics
> inheritance was perhaps one of its flaws.
> Most notably, Joe Osanna's I/O redirection paradigm. Joe was a
> Multician, but he created the pipes for Unix, not Multics. The
> Multics mechanisms for I/O redirection, like those on the Prime,
> as rather clumsy.
> That paradigm does not require fork() to be useful; fork() does
> enhance it. But Multics and PRIMOS alike would have benefited
> from that ONE SINGLE innovation.
> OTHERWISE... they were each excellent operating systems, and I
> don't get why someone would want to dump a layer of something
> else on top of it.
it became even more important, especially if you wanted to sell products
to the government.
> Now, I totally get wanting to find STVOS/Prime from the standpoint
> of software archaeology, of wanting to preserve each and every bit
> that ever ran on those machines.
> But golly gosh, if you want a Unix-like operating system, there
> are *dozens* of choices out there.
was a real, native Unix for Primes but after backing all the work in the
end Prime refused to let the developers release it apparently to protect
the market for their extremely inferior PRIMIX product.
> OTOH, if you want a Multics-like operating system, there are like,
> three choices (Multics, PRIMOS, and NOS/VE). Maybe one or two
> others.
> Ok, I'll stop ranting. Sorry. But one of my long-time favorite
> internet ranters is lying on his deathbed, and its got me into
> a mess.
for why something was actually done. Reading Debbie Scherrer's original
paper would go a long way towards understanding the goals of the project.
Daiyu Hurst
Dec 14, 2012, 11:02:25 AM12/14/12
to
On Dec 14, 8:07 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> In article <badcca16-ee32-499e-b50e-0d1e5f1d7...@j4g2000yqh.googlegroups.com>,
capability-based
operating systems and languages like ADA.
The MIT-CADR, LMI-CADR, LM-2, et. al, and the follow-on Symbolics
LISP Machine were designed to run LISP, as were some machines from
TI and Xerox.
Rockwell, Patriot Scientific, and of course, Sun, have designed and
sold JAVA CPUs.
Mushroom, J-Machine, and SOAR (Smalltalk On A RISC) were designed to
run Smalltalk. <3
The University of Illinois Zephyr machines were 4-CPU clones of the
CDC 6400, done in ECL, but lacking peripheral processors, and were
designed specifically to run PLATO.
The Burroughs B5000 was designed to run Algol-60.
Multics was designed for a machine that didn't yet exist. On the
GE645,
the rings of protection had to emulated. The target for Multics was
the
645FO (Follow-On), which sadly never got built. Instead Honeywell
built
the 6000 series machines, some of which contained the minimal features
Multics needed to run.
And of course, Prime took their early Honeywell-based CPUs and added
to
them the features needed to run PRIMOS IV, which was always intended
to
be Prime's vision of a second-generation Multics.
And there are countless re-implementations of machine architectures
that
have been created specifically to take advantage of an existing base
of
software. And I'm not referring to more modern machine designs done
by
the company that did the originals. I'm thinking even of hobbyists who
have done their own FPGA implementations of the mainframe
architectures
they loved.
No, I'll say it again, a different way. Hardware first is the cart
leading
the horse. Software first is the horse leading the cart, as it should
be.
> > So I totally fail to comprehend the value of STVOS/Prime, in a way
> > that I don't fail to comprehend Primix: Primix was a product, it
> > was meant to make money.
>
> Having worked with PRIMIX a lot from the very beginning (My printed manuals
> are xeroxs of Primes development pages!) I can tell you it was a totally
> worthless product. The primary reason for things like PRIMIX and EUNICE
> were to open up the world of Unix freeware (yes, we had freeware long before
> the Stallman rant) to other OSes. It was all about a common API accross
> multiple platforms. Long after STVOS was abandoned and lost all the work
> was re-done in the form of POSIX.
I get this. But wouldn't you want to choose the platform for all that
freeware
that *most readily* lends itself to exploiting it? But then again, if
the only
tool you have is a hammer, pretty soon everything begins to look like
a nail.
So if a PRIME is all you got, I guess you have to make do. But, I
don't think
very many people are in that position today.
Freeware sourcecode today is not easy to port, due to complex
dependencies on
other software, and incomprehensible build automation systems. First
came a
few tools to make building easier. Then tools to make building the
building
tools easier. Work turned to meta-work to meta^meta-work.
Most of the software I carried to the Prime from the Control Data
machines
I'd worked on previously, was easier to port (from a 60-bit word
machine to
a 32-bit word machine) than it is today to port a program that builds
and
runs fine on an x86 box running Linux, to an x86 box running Darwin.
Someone started a port of gcc to prime ages ago, but even if they ever
finished it, I think it was gcc 1.x, so I doubt you could get much
modern freeware ported to it with ease.
Now, as to APIs.... a universal API was the long-sought Holy Grail of
programming. Guess what? We finally got it. It's called the World Wide
Web.
The web even comprises a living descendant to a segmented virtual
memory,
in that each web page link is a symbolic address into a huge virtual
space
(thanks to PJ Denning for pointing that out).
> See above. it was all about a common API and with the advent of POSIX
> it became even more important, especially if you wanted to sell products
> to the government.
I was taught early on as a programmer, to isolate platform-specific
details
of application programs into separately-coded modules, to make porting
the
application easier. I was horrified the first time I saw a BASIC
program on
the PC that "jumped" into the BIOS ROM to accomplish something.
> Except that STVOS was never really an OS. It's an API. Of course, there
> was a real, native Unix for Primes but after backing all the work in the
> end Prime refused to let the developers release it apparently to protect
> the market for their extremely inferior PRIMIX product.
Again, I don't see the point. PRIMOS had its own API. As I come back
to
look at it in detail after a long absence, I'm amazed at how it
evolved.
In most cases, different APIs provide equivalent ways to do things, so
if
you isolate the platform-specific details, you only have to change
them
in one place. The sole exception to this seems to be how so many *nix
platforms lack a way to check for a keypress without echoing it, then
to read the key if it was pressed, and act on it accordingly. When I
looked into this recently, I found many people asking the same
question,
how to do it, and most of the *nix world just said "why on earth do
you
want to do that, are you writing a password entry routine, if so, call
<xxx> and you're done."
I suppose these folks had never written machine emulators that need to
interact with host hardware transparently, in order to let the
emulated
machine's software treat it accordingly.
> Nothing wrong with a rant. Especially if it brings out the explanation
> for why something was actually done. Reading Debbie Scherrer's original
> paper would go a long way towards understanding the goals of the project.
I did read it, and I get it, I just disagree with the premise.
The kind of universal API proposed, I find of limited or no value.
But I think it's nonetheless important to find and preserve this
software.
How else can we learn from our mistakes?
-dai
> In article <badcca16-ee32-499e-b50e-0d1e5f1d7...@j4g2000yqh.googlegroups.com>,
> Daiyu Hurst <daiyu.hu...@gmail.com> writes:
> > On Dec 13, 8:57 pm, d...@ihatespam.msu.edu (Dennis Boone) wrote:
> >> > Folks, does this look like the Holy Grail of which we speak? I got
> >> > this from a member of my Control Data group; it appears to be the
> >> > portable distribution, un-ported.
>
> >> I'm pretty sure GATech made some enhancements to integrate the
> >> basic STOS with PRIMOS. Here's the User Guide for the GATech
> >> version:
>
> >>http://yagi.h-net.msu.edu/prime_manuals/GIT-ICS-85-08_Software_Tools_...
>
> >> De
> > I confess...
> > I'm a computer programmer at heart. Jim's sig line (or the one he
> > used to use) expresses my feelings very succinctly:
> > Software First! (Software Lasts!)
> > Pick the software you want. Then find the hardware that best runs it.
> > If the hardware doesn't exist, design it and build it.
>
> With the single exception of The UCSD-Pascal Microengine, name one case
> where this was what happened. Hardware invariably come first. Probably
> because it's a lot easier to customize software to fit on the hardware
> than the other way around.
The Intel iAPX432 CPU chipset was designed as a platform for
> > On Dec 13, 8:57 pm, d...@ihatespam.msu.edu (Dennis Boone) wrote:
> >> > Folks, does this look like the Holy Grail of which we speak? I got
> >> > this from a member of my Control Data group; it appears to be the
> >> > portable distribution, un-ported.
>
> >> I'm pretty sure GATech made some enhancements to integrate the
> >> basic STOS with PRIMOS. Here's the User Guide for the GATech
> >> version:
>
> >>http://yagi.h-net.msu.edu/prime_manuals/GIT-ICS-85-08_Software_Tools_...
>
> >> De
> > I confess...
> > I'm a computer programmer at heart. Jim's sig line (or the one he
> > used to use) expresses my feelings very succinctly:
> > Software First! (Software Lasts!)
> > Pick the software you want. Then find the hardware that best runs it.
> > If the hardware doesn't exist, design it and build it.
>
> With the single exception of The UCSD-Pascal Microengine, name one case
> where this was what happened. Hardware invariably come first. Probably
> because it's a lot easier to customize software to fit on the hardware
> than the other way around.
capability-based
operating systems and languages like ADA.
The MIT-CADR, LMI-CADR, LM-2, et. al, and the follow-on Symbolics
LISP Machine were designed to run LISP, as were some machines from
TI and Xerox.
Rockwell, Patriot Scientific, and of course, Sun, have designed and
sold JAVA CPUs.
Mushroom, J-Machine, and SOAR (Smalltalk On A RISC) were designed to
run Smalltalk. <3
The University of Illinois Zephyr machines were 4-CPU clones of the
CDC 6400, done in ECL, but lacking peripheral processors, and were
designed specifically to run PLATO.
The Burroughs B5000 was designed to run Algol-60.
Multics was designed for a machine that didn't yet exist. On the
GE645,
the rings of protection had to emulated. The target for Multics was
the
645FO (Follow-On), which sadly never got built. Instead Honeywell
built
the 6000 series machines, some of which contained the minimal features
Multics needed to run.
And of course, Prime took their early Honeywell-based CPUs and added
to
them the features needed to run PRIMOS IV, which was always intended
to
be Prime's vision of a second-generation Multics.
And there are countless re-implementations of machine architectures
that
have been created specifically to take advantage of an existing base
of
software. And I'm not referring to more modern machine designs done
by
the company that did the originals. I'm thinking even of hobbyists who
have done their own FPGA implementations of the mainframe
architectures
they loved.
No, I'll say it again, a different way. Hardware first is the cart
leading
the horse. Software first is the horse leading the cart, as it should
be.
> > So I totally fail to comprehend the value of STVOS/Prime, in a way
> > that I don't fail to comprehend Primix: Primix was a product, it
> > was meant to make money.
>
> Having worked with PRIMIX a lot from the very beginning (My printed manuals
> are xeroxs of Primes development pages!) I can tell you it was a totally
> worthless product. The primary reason for things like PRIMIX and EUNICE
> were to open up the world of Unix freeware (yes, we had freeware long before
> the Stallman rant) to other OSes. It was all about a common API accross
> multiple platforms. Long after STVOS was abandoned and lost all the work
> was re-done in the form of POSIX.
freeware
that *most readily* lends itself to exploiting it? But then again, if
the only
tool you have is a hammer, pretty soon everything begins to look like
a nail.
So if a PRIME is all you got, I guess you have to make do. But, I
don't think
very many people are in that position today.
Freeware sourcecode today is not easy to port, due to complex
dependencies on
other software, and incomprehensible build automation systems. First
came a
few tools to make building easier. Then tools to make building the
building
tools easier. Work turned to meta-work to meta^meta-work.
Most of the software I carried to the Prime from the Control Data
machines
I'd worked on previously, was easier to port (from a 60-bit word
machine to
a 32-bit word machine) than it is today to port a program that builds
and
runs fine on an x86 box running Linux, to an x86 box running Darwin.
Someone started a port of gcc to prime ages ago, but even if they ever
finished it, I think it was gcc 1.x, so I doubt you could get much
modern freeware ported to it with ease.
Now, as to APIs.... a universal API was the long-sought Holy Grail of
programming. Guess what? We finally got it. It's called the World Wide
Web.
The web even comprises a living descendant to a segmented virtual
memory,
in that each web page link is a symbolic address into a huge virtual
space
(thanks to PJ Denning for pointing that out).
> See above. it was all about a common API and with the advent of POSIX
> it became even more important, especially if you wanted to sell products
> to the government.
details
of application programs into separately-coded modules, to make porting
the
application easier. I was horrified the first time I saw a BASIC
program on
the PC that "jumped" into the BIOS ROM to accomplish something.
> Except that STVOS was never really an OS. It's an API. Of course, there
> was a real, native Unix for Primes but after backing all the work in the
> end Prime refused to let the developers release it apparently to protect
> the market for their extremely inferior PRIMIX product.
to
look at it in detail after a long absence, I'm amazed at how it
evolved.
In most cases, different APIs provide equivalent ways to do things, so
if
you isolate the platform-specific details, you only have to change
them
in one place. The sole exception to this seems to be how so many *nix
platforms lack a way to check for a keypress without echoing it, then
to read the key if it was pressed, and act on it accordingly. When I
looked into this recently, I found many people asking the same
question,
how to do it, and most of the *nix world just said "why on earth do
you
want to do that, are you writing a password entry routine, if so, call
<xxx> and you're done."
I suppose these folks had never written machine emulators that need to
interact with host hardware transparently, in order to let the
emulated
machine's software treat it accordingly.
> Nothing wrong with a rant. Especially if it brings out the explanation
> for why something was actually done. Reading Debbie Scherrer's original
> paper would go a long way towards understanding the goals of the project.
The kind of universal API proposed, I find of limited or no value.
But I think it's nonetheless important to find and preserve this
software.
How else can we learn from our mistakes?
-dai
Andreas Eder
Dec 14, 2012, 11:08:18 AM12/14/12
to
>>>>> "Bill" == Bill Gunshannon <bill...@cs.uofs.edu> writes:
Bill> With the single exception of The UCSD-Pascal Microengine, name one case
Bill> where this was what happened. Hardware invariably come first. Probably
Bill> because it's a lot easier to customize software to fit on the hardware
Bill> than the other way around.
What about the Lisp Machines? Symbolics and LMI and TI?
'Andreas
--
ceterum censeo redmondinem esse delendam.
Bill> With the single exception of The UCSD-Pascal Microengine, name one case
Bill> where this was what happened. Hardware invariably come first. Probably
Bill> because it's a lot easier to customize software to fit on the hardware
Bill> than the other way around.
What about the Lisp Machines? Symbolics and LMI and TI?
'Andreas
--
ceterum censeo redmondinem esse delendam.
Bill Gunshannon
Dec 14, 2012, 12:11:24 PM12/14/12
to
In article <1b811bb7-a9e0-4efb...@b8g2000yqh.googlegroups.com>,
OK, I see where you are going but being designed with feature to
support a language or concept is not the same thing as writing
the OS and then building a machine to run it. i did find the
comment avout Javacode hardware interesting. I will need to
research that a bit (out of curiosity). Especially being as SUN
was always totally against making a Java compiler that generated
code that was native to a processor. The Javacode cpu would be
very impractical as bytecode seems to be constantly in flux. It's
really hard to hit a moving target. :-)
>> > So I totally fail to comprehend the value of STVOS/Prime, in a way
>> > that I don't fail to comprehend Primix: Primix was a product, it
>> > was meant to make money.
>>
>> Having worked with PRIMIX a lot from the very beginning (My printed manuals
>> are xeroxs of Primes development pages!) I can tell you it was a totally
>> worthless product. The primary reason for things like PRIMIX and EUNICE
>> were to open up the world of Unix freeware (yes, we had freeware long before
>> the Stallman rant) to other OSes. It was all about a common API accross
>> multiple platforms. Long after STVOS was abandoned and lost all the work
>> was re-done in the form of POSIX.
> I get this. But wouldn't you want to choose the platform for all that
> freeware
> that *most readily* lends itself to exploiting it? But then again, if
> the only
> tool you have is a hammer, pretty soon everything begins to look like
> a nail.
Unless you see a world with only one type of system, this variety is
unavoidable. People will develop for the machine they are working on.
If the software is generally usable other people will want to see it
on their system as well.
> So if a PRIME is all you got, I guess you have to make do. But, I
> don't think
> very many people are in that position today.
> Freeware sourcecode today is not easy to port, due to complex
> dependencies on
> other software, and incomprehensible build automation systems. First
That has nothing to do with the systems they run on or the API. that
has to do with lack of coordination of the developers. But given a
program, if it uses an API common among many systems the program can
be ported. If there is no common API then porting becomes difficult
if not impossible. Try porting anything to VMS that needs fork().
Or, better still, try porting anything to a Prime that assumes the
values of ASCII characters falls between 0 and 127 (and lot's of
unix software does!!)
> came a
> few tools to make building easier. Then tools to make building the
> building
> tools easier. Work turned to meta-work to meta^meta-work.
> Most of the software I carried to the Prime from the Control Data
> machines
> I'd worked on previously, was easier to port (from a 60-bit word
> machine to
> a 32-bit word machine) than it is today to port a program that builds
> and
> runs fine on an x86 box running Linux, to an x86 box running Darwin.
I don't see why that wold be so hard. Both are just different dialects
of the same OS. A more intersting problem is going to be porting a
lot of the existing software from 32bit intel to 64bit intel. But
even that is really the fault of poor development control. (think:
pointer converted to integer without a cast)
> Someone started a port of gcc to prime ages ago, but even if they ever
> finished it, I think it was gcc 1.x, so I doubt you could get much
> modern freeware ported to it with ease.
Based on personal experience, the biggest problem with porting common
unix software to Primos was the ASCII problem. It breaks most parsers
which assume values between 0 and 127. And then we have the NULL issue.
What do you think the numeric value of NULL under Prime C was? :-)
Hint: it certainly wasn't 0. How many programs do you think that breaks?
> Now, as to APIs.... a universal API was the long-sought Holy Grail of
> programming. Guess what? We finally got it. It's called the World Wide
> Web.
Sorry, that is hardly an API. I work with a lot of systems that have no
and will never have access to the "World Wide Web" (whatever that is).
Having an API does not mean running Java off the INTERNET.
> The web even comprises a living descendant to a segmented virtual
> memory,
> in that each web page link is a symbolic address into a huge virtual
> space
> (thanks to PJ Denning for pointing that out).
>> See above. it was all about a common API and with the advent of POSIX
>> it became even more important, especially if you wanted to sell products
>> to the government.
> I was taught early on as a programmer, to isolate platform-specific
> details
> of application programs into separately-coded modules, to make porting
> the
> application easier.
Which usually works except when the developer doesn't think anyone
else is ever going to be interested in his program.
> I was horrified the first time I saw a BASIC
> program on
> the PC that "jumped" into the BIOS ROM to accomplish something.
Hindsight is always 20/20. I too have seen this done often, usually as
a means of saving memory which was, in those days, very precious. (My
first mchine supporting BASIC had 4K of RAM.)
>> Except that STVOS was never really an OS. It's an API. Of course, there
>> was a real, native Unix for Primes but after backing all the work in the
>> end Prime refused to let the developers release it apparently to protect
>> the market for their extremely inferior PRIMIX product.
> Again, I don't see the point. PRIMOS had its own API. As I come back
> to
> look at it in detail after a long absence, I'm amazed at how it
> evolved.
Yes, it did. One that it did not share with any other system making
porting software to/from Primos extremely difficult, if not impossible.
Sadly, Prime lived in a vacuum thinking it was the only system in the
industry. It paid the price.
> In most cases, different APIs provide equivalent ways to do things, so
> if
> you isolate the platform-specific details, you only have to change
> them
> in one place.
If you develop to a common API you don't have to change them at all.
> The sole exception to this seems to be how so many *nix
> platforms lack a way to check for a keypress without echoing it,
Name them. I have never seen such a system and I have been doing Unix
for 30 years.
> then
> to read the key if it was pressed, and act on it accordingly. When I
> looked into this recently, I found many people asking the same
> question,
> how to do it, and most of the *nix world just said "why on earth do
> you
> want to do that, are you writing a password entry routine, if so, call
> <xxx> and you're done."
You talk to some very strange unix people. I can think of at least two
ways to do this right off the top of my head.
> I suppose these folks had never written machine emulators that need to
> interact with host hardware transparently, in order to let the
> emulated
> machine's software treat it accordingly.
Sorry, I can't even begin to understand what this means.
>> Nothing wrong with a rant. Especially if it brings out the explanation
>> for why something was actually done. Reading Debbie Scherrer's original
>> paper would go a long way towards understanding the goals of the project.
> I did read it, and I get it, I just disagree with the premise.
> The kind of universal API proposed, I find of limited or no value.
> But I think it's nonetheless important to find and preserve this
> software.
Well, I guess the people who reinvented the wqheel to give us POSIX
didn't agree with you. :-)
> How else can we learn from our mistakes?
Sadly, at least in this industry, people seldom do. They just go back
and re-invent the wheel with all the same mistakes.
support a language or concept is not the same thing as writing
the OS and then building a machine to run it. i did find the
comment avout Javacode hardware interesting. I will need to
research that a bit (out of curiosity). Especially being as SUN
was always totally against making a Java compiler that generated
code that was native to a processor. The Javacode cpu would be
very impractical as bytecode seems to be constantly in flux. It's
really hard to hit a moving target. :-)
>> > So I totally fail to comprehend the value of STVOS/Prime, in a way
>> > that I don't fail to comprehend Primix: Primix was a product, it
>> > was meant to make money.
>>
>> Having worked with PRIMIX a lot from the very beginning (My printed manuals
>> are xeroxs of Primes development pages!) I can tell you it was a totally
>> worthless product. The primary reason for things like PRIMIX and EUNICE
>> were to open up the world of Unix freeware (yes, we had freeware long before
>> the Stallman rant) to other OSes. It was all about a common API accross
>> multiple platforms. Long after STVOS was abandoned and lost all the work
>> was re-done in the form of POSIX.
> I get this. But wouldn't you want to choose the platform for all that
> freeware
> that *most readily* lends itself to exploiting it? But then again, if
> the only
> tool you have is a hammer, pretty soon everything begins to look like
> a nail.
unavoidable. People will develop for the machine they are working on.
If the software is generally usable other people will want to see it
on their system as well.
> So if a PRIME is all you got, I guess you have to make do. But, I
> don't think
> very many people are in that position today.
> Freeware sourcecode today is not easy to port, due to complex
> dependencies on
> other software, and incomprehensible build automation systems. First
has to do with lack of coordination of the developers. But given a
program, if it uses an API common among many systems the program can
be ported. If there is no common API then porting becomes difficult
if not impossible. Try porting anything to VMS that needs fork().
Or, better still, try porting anything to a Prime that assumes the
values of ASCII characters falls between 0 and 127 (and lot's of
unix software does!!)
> came a
> few tools to make building easier. Then tools to make building the
> building
> tools easier. Work turned to meta-work to meta^meta-work.
> Most of the software I carried to the Prime from the Control Data
> machines
> I'd worked on previously, was easier to port (from a 60-bit word
> machine to
> a 32-bit word machine) than it is today to port a program that builds
> and
> runs fine on an x86 box running Linux, to an x86 box running Darwin.
of the same OS. A more intersting problem is going to be porting a
lot of the existing software from 32bit intel to 64bit intel. But
even that is really the fault of poor development control. (think:
pointer converted to integer without a cast)
> Someone started a port of gcc to prime ages ago, but even if they ever
> finished it, I think it was gcc 1.x, so I doubt you could get much
> modern freeware ported to it with ease.
unix software to Primos was the ASCII problem. It breaks most parsers
which assume values between 0 and 127. And then we have the NULL issue.
What do you think the numeric value of NULL under Prime C was? :-)
Hint: it certainly wasn't 0. How many programs do you think that breaks?
> Now, as to APIs.... a universal API was the long-sought Holy Grail of
> programming. Guess what? We finally got it. It's called the World Wide
> Web.
and will never have access to the "World Wide Web" (whatever that is).
Having an API does not mean running Java off the INTERNET.
> The web even comprises a living descendant to a segmented virtual
> memory,
> in that each web page link is a symbolic address into a huge virtual
> space
> (thanks to PJ Denning for pointing that out).
>> See above. it was all about a common API and with the advent of POSIX
>> it became even more important, especially if you wanted to sell products
>> to the government.
> I was taught early on as a programmer, to isolate platform-specific
> details
> of application programs into separately-coded modules, to make porting
> the
> application easier.
else is ever going to be interested in his program.
> I was horrified the first time I saw a BASIC
> program on
> the PC that "jumped" into the BIOS ROM to accomplish something.
a means of saving memory which was, in those days, very precious. (My
first mchine supporting BASIC had 4K of RAM.)
>> Except that STVOS was never really an OS. It's an API. Of course, there
>> was a real, native Unix for Primes but after backing all the work in the
>> end Prime refused to let the developers release it apparently to protect
>> the market for their extremely inferior PRIMIX product.
> Again, I don't see the point. PRIMOS had its own API. As I come back
> to
> look at it in detail after a long absence, I'm amazed at how it
> evolved.
porting software to/from Primos extremely difficult, if not impossible.
Sadly, Prime lived in a vacuum thinking it was the only system in the
industry. It paid the price.
> In most cases, different APIs provide equivalent ways to do things, so
> if
> you isolate the platform-specific details, you only have to change
> them
> in one place.
> The sole exception to this seems to be how so many *nix
> platforms lack a way to check for a keypress without echoing it,
for 30 years.
> then
> to read the key if it was pressed, and act on it accordingly. When I
> looked into this recently, I found many people asking the same
> question,
> how to do it, and most of the *nix world just said "why on earth do
> you
> want to do that, are you writing a password entry routine, if so, call
> <xxx> and you're done."
ways to do this right off the top of my head.
> I suppose these folks had never written machine emulators that need to
> interact with host hardware transparently, in order to let the
> emulated
> machine's software treat it accordingly.
>> Nothing wrong with a rant. Especially if it brings out the explanation
>> for why something was actually done. Reading Debbie Scherrer's original
>> paper would go a long way towards understanding the goals of the project.
> I did read it, and I get it, I just disagree with the premise.
> The kind of universal API proposed, I find of limited or no value.
> But I think it's nonetheless important to find and preserve this
> software.
didn't agree with you. :-)
> How else can we learn from our mistakes?
and re-invent the wheel with all the same mistakes.
Bill Gunshannon
Dec 14, 2012, 12:20:54 PM12/14/12
to
In article <877gokv...@eder.homelinux.net>,
than a machine with a built in language processor for Lisp. Kind of
like saying the early microcomputers (TRS-80, Commodore64, etc.) were
hardware designed to run BASIC.
Interesting read about Lisp Machines in wiki.
Andreas Eder <andrea...@gmx.net> writes:
>>>>>> "Bill" == Bill Gunshannon <bill...@cs.uofs.edu> writes:
>
> Bill> With the single exception of The UCSD-Pascal Microengine, name one case
> Bill> where this was what happened. Hardware invariably come first. Probably
> Bill> because it's a lot easier to customize software to fit on the hardware
> Bill> than the other way around.
>
> What about the Lisp Machines? Symbolics and LMI and TI?
>
I have never seen on, but ffrom what I rmember they were little more
>>>>>> "Bill" == Bill Gunshannon <bill...@cs.uofs.edu> writes:
>
> Bill> With the single exception of The UCSD-Pascal Microengine, name one case
> Bill> where this was what happened. Hardware invariably come first. Probably
> Bill> because it's a lot easier to customize software to fit on the hardware
> Bill> than the other way around.
>
> What about the Lisp Machines? Symbolics and LMI and TI?
>
than a machine with a built in language processor for Lisp. Kind of
like saying the early microcomputers (TRS-80, Commodore64, etc.) were
hardware designed to run BASIC.
Interesting read about Lisp Machines in wiki.
Daiyu Hurst
Dec 14, 2012, 8:41:21 PM12/14/12
to
On Dec 14, 12:11 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> In article <1b811bb7-a9e0-4efb-9e9c-a493e9783...@b8g2000yqh.googlegroups.com>,
mainframes had three different character sets, my experience
taught me not to make assumptions about character sets. And
I can show you some software written in FORTRAN that also avoids
assumptions like this, and is fully portable. It compiles and
runs *as is* on a CDC 6000 machine that has a 6-bit character
set and on the Prime, without any editing.
> > came a
> > few tools to make building easier. Then tools to make building the
> > building
> > tools easier. Work turned to meta-work to meta^meta-work.
> > Most of the software I carried to the Prime from the Control Data
> > machines
> > I'd worked on previously, was easier to port (from a 60-bit word
> > machine to
> > a 32-bit word machine) than it is today to port a program that builds
> > and
> > runs fine on an x86 box running Linux, to an x86 box running Darwin.
>
> I don't see why that wold be so hard. Both are just different dialects
> of the same OS. A more intersting problem is going to be porting a
> lot of the existing software from 32bit intel to 64bit intel. But
> even that is really the fault of poor development control. (think:
> pointer converted to integer without a cast)
If you have a copy of VMware, you can download this virtual machine
containing
Darwin 8.0.1; it has 3 different versions of gcc on it, but if you
wanted a
version other than the three supplied, I think you would it more
difficult to
get another version to build than you would feel is worth the effort.
https://docs.google.com/open?id=0ByJs3HoO8aRVck9JSkwyOVBLMUU
it also has MacPorts installed on it, but most ports will not install,
since
they assume you're running MacOSX machine, rather than Darwin.
> > Someone started a port of gcc to prime ages ago, but even if they ever
> > finished it, I think it was gcc 1.x, so I doubt you could get much
> > modern freeware ported to it with ease.
>
> Based on personal experience, the biggest problem with porting common
> unix software to Primos was the ASCII problem. It breaks most parsers
> which assume values between 0 and 127. And then we have the NULL issue.
> What do you think the numeric value of NULL under Prime C was? :-)
> Hint: it certainly wasn't 0. How many programs do you think that breaks?
Again, this is due to poor design assumptions by the original
programmer.
The value of the expression [literal "A" minus literal "@"] is always
the
same, whether its on a Prime or on MS-DOS.
> > Now, as to APIs.... a universal API was the long-sought Holy Grail of
> > programming. Guess what? We finally got it. It's called the World Wide
> > Web.
>
> Sorry, that is hardly an API. I work with a lot of systems that have no
> and will never have access to the "World Wide Web" (whatever that is).
> Having an API does not mean running Java off the INTERNET.
The web actually has a number of APIs; of course I really meant to
say, the
web is the universal applications platform. I think you can even do
stuff
like EDI and CICS via webapps now.
> > The web even comprises a living descendant to a segmented virtual
> > memory,
> > in that each web page link is a symbolic address into a huge virtual
> > space
> > (thanks to PJ Denning for pointing that out).
> >> See above. it was all about a common API and with the advent of POSIX
> >> it became even more important, especially if you wanted to sell products
> >> to the government.
> > I was taught early on as a programmer, to isolate platform-specific
> > details
> > of application programs into separately-coded modules, to make porting
> > the
> > application easier.
>
> Which usually works except when the developer doesn't think anyone
> else is ever going to be interested in his program.
In which case they're just going to be lazy and not do as I outlined.
> > I was horrified the first time I saw a BASIC
> > program on
> > the PC that "jumped" into the BIOS ROM to accomplish something.
>
> Hindsight is always 20/20. I too have seen this done often, usually as
> a means of saving memory which was, in those days, very precious. (My
> first mchine supporting BASIC had 4K of RAM.)
Ah, expediency makes it ok.
> >> Except that STVOS was never really an OS. It's an API. Of course, there
> >> was a real, native Unix for Primes but after backing all the work in the
> >> end Prime refused to let the developers release it apparently to protect
> >> the market for their extremely inferior PRIMIX product.
> > Again, I don't see the point. PRIMOS had its own API. As I come back
> > to
> > look at it in detail after a long absence, I'm amazed at how it
> > evolved.
>
> Yes, it did. One that it did not share with any other system making
> porting software to/from Primos extremely difficult, if not impossible.
> Sadly, Prime lived in a vacuum thinking it was the only system in the
> industry. It paid the price.
I don't think Prime's software technology played any role in their
demise.
Bad business decisions and the LowBlow takeover was what killed them.
> > In most cases, different APIs provide equivalent ways to do things, so
> > if
> > you isolate the platform-specific details, you only have to change
> > them
> > in one place.
>
> If you develop to a common API you don't have to change them at all.
One's order is another's chaos.
> > The sole exception to this seems to be how so many *nix
> > platforms lack a way to check for a keypress without echoing it,
>
> Name them. I have never seen such a system and I have been doing Unix
> for 30 years.
I misstated that I meant to say, there is no single portable solution
to
this. Each system tends to provide its own way. So in fact there is no
"Unix Way" to check for a keypress, process the keypress if it
happened,
but not echo it back out again, unless the program does so itself.
> > to read the key if it was pressed, and act on it accordingly. When I
> > looked into this recently, I found many people asking the same
> > question,
> > how to do it, and most of the *nix world just said "why on earth do
> > you
> > want to do that, are you writing a password entry routine, if so, call
> > <xxx> and you're done."
>
> You talk to some very strange unix people. I can think of at least two
> ways to do this right off the top of my head.
yes, I misstated the problem. It's doable on every system, but there
seems
to be no universal way to do it. Look at the variety offered here:
http://stackoverflow.com/questions/421860/c-c-capture-characters-from-standard-input-without-waiting-for-enter-to-be-pr
> > I suppose these folks had never written machine emulators that need to
> > interact with host hardware transparently, in order to let the
> > emulated
> > machine's software treat it accordingly.
>
> Sorry, I can't even begin to understand what this means.
If you're writing an machine emulator, and you're going to run an
operating
system on it, and that operating system wants to talk to a keyboard,
and
do so in either half-duplex (and thus not echo the characters) or in
full-duplex
(and thus echo the characters). The decision to echo shouldn't be made
by the
runtime library of the language you wrote the emulator in, or the
operating
system of the computer that hosts the emulator. The decision needs to
be made
by the operating system running on the emulator.
I hope that's clearer.
> >> Nothing wrong with a rant. Especially if it brings out the explanation
> >> for why something was actually done. Reading Debbie Scherrer's original
> >> paper would go a long way towards understanding the goals of the project.
> > I did read it, and I get it, I just disagree with the premise.
> > The kind of universal API proposed, I find of limited or no value.
> > But I think it's nonetheless important to find and preserve this
> > software.
>
> Well, I guess the people who reinvented the wqheel to give us POSIX
> didn't agree with you. :-)
OS designers have been picking and choosing what bits from POSIX they
wish to implement. Yes, generally, for whatever portions DO get
implemented,
those tend to respond as expected. I tend to think another reason it
works
well is due to the lack of diversity in processor architectures these
days.
> > How else can we learn from our mistakes?
>
> Sadly, at least in this industry, people seldom do. They just go back
> and re-invent the wheel with all the same mistakes.
PJ Denning had an interesting, fatherly perspective on this:
"You may have wondered why virtual memory, so popular in the operating
systems of the 1960s and 1970s, was not present in the personal-
computer
operating systems of the 1980s. The pundits of the microcomputer
revolution
proclaimed bravely that personal computers would not succumb to the
diseases
of the large commercial operating systems; the personal computer would
be
simple, fast, and cheap. Bill Gates, who once said that no user of a
personal
computer would ever need more than 640K of main memory, brought out
Microsoft DOS in 1982 without most of the common operating system
functions,
including virtual memory. Over time, however, programmers of personal
computers encountered exactly the same programming problems as their
predecessors in the 1950s, 1960s, and 1970s. That put pressure on the
major PC
operating system makers (Apple, Microsoft, and IBM) to add
multiprogramming
and virtual memory to their operating systems. These makers were able
to
respond positively because the major chip builders had never lost
faith; Intel
offered virtual memory and cache in its 80386 chip in 1985; and
Motorola did
likewise in its 68020 chip. Apple offered multiprogramming in its
MultiFinder
and virtual memory in its System 6 operating system. Microsoft offered
multiprogramming in Windows 3.1 and virtual memory in Windows 95. IBM
offered multiprogramming and virtual memory in OS/2."
and
"From time to time over the past forty years, various people have
argued that
virtual memory is not really necessary because advancing memory
technology
would soon permit us to have all the random-access main memory we
could
possibly want. Such predictions assume implicitly that the primary
reason for
virtual memory is automatic storage allocation of a memory hierarchy.
The
historical record reveals, to the contrary, that the driving force
behind virtual
memory has always been simplifying programs (and programming) by
insulating algorithms from the parameters of the memory configuration
and by
allowing separately constructed objects to be shared, reused, and
protected. The
predictions that memory capacities would eventually be large enough to
hold
everything have never come true and there is little reason to believe
they ever
will. And even if they did, each new generation of users has
discovered that its
ambitions for sharing objects led it to virtual memory. Virtual memory
accommodates essential patterns in the way people use computers. It
will still be
used when we are all gone."
(taken from "Before Memory was Virtual"
http://denninginstitute.com/pjd/PUBS/bvm.pdf
-dai
> In article <1b811bb7-a9e0-4efb-9e9c-a493e9783...@b8g2000yqh.googlegroups.com>,
> Daiyu Hurst <daiyu.hu...@gmail.com> writes:
> > On Dec 14, 8:07 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> > So if a PRIME is all you got, I guess you have to make do. But, I
> > don't think
> > very many people are in that position today.
> > Freeware sourcecode today is not easy to port, due to complex
> > dependencies on
> > other software, and incomprehensible build automation systems. First
>
> That has nothing to do with the systems they run on or the API. that
> has to do with lack of coordination of the developers. But given a
> program, if it uses an API common among many systems the program can
> be ported. If there is no common API then porting becomes difficult
> if not impossible. Try porting anything to VMS that needs fork().
> Or, better still, try porting anything to a Prime that assumes the
> values of ASCII characters falls between 0 and 127 (and lot's of
> unix software does!!)
Having gotten my start in an environment where three different
> > On Dec 14, 8:07 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> > So if a PRIME is all you got, I guess you have to make do. But, I
> > don't think
> > very many people are in that position today.
> > Freeware sourcecode today is not easy to port, due to complex
> > dependencies on
> > other software, and incomprehensible build automation systems. First
>
> That has nothing to do with the systems they run on or the API. that
> has to do with lack of coordination of the developers. But given a
> program, if it uses an API common among many systems the program can
> be ported. If there is no common API then porting becomes difficult
> if not impossible. Try porting anything to VMS that needs fork().
> Or, better still, try porting anything to a Prime that assumes the
> values of ASCII characters falls between 0 and 127 (and lot's of
> unix software does!!)
mainframes had three different character sets, my experience
taught me not to make assumptions about character sets. And
I can show you some software written in FORTRAN that also avoids
assumptions like this, and is fully portable. It compiles and
runs *as is* on a CDC 6000 machine that has a 6-bit character
set and on the Prime, without any editing.
> > came a
> > few tools to make building easier. Then tools to make building the
> > building
> > tools easier. Work turned to meta-work to meta^meta-work.
> > Most of the software I carried to the Prime from the Control Data
> > machines
> > I'd worked on previously, was easier to port (from a 60-bit word
> > machine to
> > a 32-bit word machine) than it is today to port a program that builds
> > and
> > runs fine on an x86 box running Linux, to an x86 box running Darwin.
>
> I don't see why that wold be so hard. Both are just different dialects
> of the same OS. A more intersting problem is going to be porting a
> lot of the existing software from 32bit intel to 64bit intel. But
> even that is really the fault of poor development control. (think:
> pointer converted to integer without a cast)
containing
Darwin 8.0.1; it has 3 different versions of gcc on it, but if you
wanted a
version other than the three supplied, I think you would it more
difficult to
get another version to build than you would feel is worth the effort.
https://docs.google.com/open?id=0ByJs3HoO8aRVck9JSkwyOVBLMUU
it also has MacPorts installed on it, but most ports will not install,
since
they assume you're running MacOSX machine, rather than Darwin.
> > Someone started a port of gcc to prime ages ago, but even if they ever
> > finished it, I think it was gcc 1.x, so I doubt you could get much
> > modern freeware ported to it with ease.
>
> Based on personal experience, the biggest problem with porting common
> unix software to Primos was the ASCII problem. It breaks most parsers
> which assume values between 0 and 127. And then we have the NULL issue.
> What do you think the numeric value of NULL under Prime C was? :-)
> Hint: it certainly wasn't 0. How many programs do you think that breaks?
programmer.
The value of the expression [literal "A" minus literal "@"] is always
the
same, whether its on a Prime or on MS-DOS.
> > Now, as to APIs.... a universal API was the long-sought Holy Grail of
> > programming. Guess what? We finally got it. It's called the World Wide
> > Web.
>
> Sorry, that is hardly an API. I work with a lot of systems that have no
> and will never have access to the "World Wide Web" (whatever that is).
> Having an API does not mean running Java off the INTERNET.
say, the
web is the universal applications platform. I think you can even do
stuff
like EDI and CICS via webapps now.
> > The web even comprises a living descendant to a segmented virtual
> > memory,
> > in that each web page link is a symbolic address into a huge virtual
> > space
> > (thanks to PJ Denning for pointing that out).
> >> See above. it was all about a common API and with the advent of POSIX
> >> it became even more important, especially if you wanted to sell products
> >> to the government.
> > I was taught early on as a programmer, to isolate platform-specific
> > details
> > of application programs into separately-coded modules, to make porting
> > the
> > application easier.
>
> Which usually works except when the developer doesn't think anyone
> else is ever going to be interested in his program.
> > I was horrified the first time I saw a BASIC
> > program on
> > the PC that "jumped" into the BIOS ROM to accomplish something.
>
> Hindsight is always 20/20. I too have seen this done often, usually as
> a means of saving memory which was, in those days, very precious. (My
> first mchine supporting BASIC had 4K of RAM.)
> >> Except that STVOS was never really an OS. It's an API. Of course, there
> >> was a real, native Unix for Primes but after backing all the work in the
> >> end Prime refused to let the developers release it apparently to protect
> >> the market for their extremely inferior PRIMIX product.
> > Again, I don't see the point. PRIMOS had its own API. As I come back
> > to
> > look at it in detail after a long absence, I'm amazed at how it
> > evolved.
>
> Yes, it did. One that it did not share with any other system making
> porting software to/from Primos extremely difficult, if not impossible.
> Sadly, Prime lived in a vacuum thinking it was the only system in the
> industry. It paid the price.
demise.
Bad business decisions and the LowBlow takeover was what killed them.
> > In most cases, different APIs provide equivalent ways to do things, so
> > if
> > you isolate the platform-specific details, you only have to change
> > them
> > in one place.
>
> If you develop to a common API you don't have to change them at all.
> > The sole exception to this seems to be how so many *nix
> > platforms lack a way to check for a keypress without echoing it,
>
> Name them. I have never seen such a system and I have been doing Unix
> for 30 years.
to
this. Each system tends to provide its own way. So in fact there is no
"Unix Way" to check for a keypress, process the keypress if it
happened,
but not echo it back out again, unless the program does so itself.
> > to read the key if it was pressed, and act on it accordingly. When I
> > looked into this recently, I found many people asking the same
> > question,
> > how to do it, and most of the *nix world just said "why on earth do
> > you
> > want to do that, are you writing a password entry routine, if so, call
> > <xxx> and you're done."
>
> You talk to some very strange unix people. I can think of at least two
> ways to do this right off the top of my head.
seems
to be no universal way to do it. Look at the variety offered here:
http://stackoverflow.com/questions/421860/c-c-capture-characters-from-standard-input-without-waiting-for-enter-to-be-pr
> > I suppose these folks had never written machine emulators that need to
> > interact with host hardware transparently, in order to let the
> > emulated
> > machine's software treat it accordingly.
>
> Sorry, I can't even begin to understand what this means.
operating
system on it, and that operating system wants to talk to a keyboard,
and
do so in either half-duplex (and thus not echo the characters) or in
full-duplex
(and thus echo the characters). The decision to echo shouldn't be made
by the
runtime library of the language you wrote the emulator in, or the
operating
system of the computer that hosts the emulator. The decision needs to
be made
by the operating system running on the emulator.
I hope that's clearer.
> >> Nothing wrong with a rant. Especially if it brings out the explanation
> >> for why something was actually done. Reading Debbie Scherrer's original
> >> paper would go a long way towards understanding the goals of the project.
> > I did read it, and I get it, I just disagree with the premise.
> > The kind of universal API proposed, I find of limited or no value.
> > But I think it's nonetheless important to find and preserve this
> > software.
>
> Well, I guess the people who reinvented the wqheel to give us POSIX
> didn't agree with you. :-)
wish to implement. Yes, generally, for whatever portions DO get
implemented,
those tend to respond as expected. I tend to think another reason it
works
well is due to the lack of diversity in processor architectures these
days.
> > How else can we learn from our mistakes?
>
> Sadly, at least in this industry, people seldom do. They just go back
> and re-invent the wheel with all the same mistakes.
"You may have wondered why virtual memory, so popular in the operating
systems of the 1960s and 1970s, was not present in the personal-
computer
operating systems of the 1980s. The pundits of the microcomputer
revolution
proclaimed bravely that personal computers would not succumb to the
diseases
of the large commercial operating systems; the personal computer would
be
simple, fast, and cheap. Bill Gates, who once said that no user of a
personal
computer would ever need more than 640K of main memory, brought out
Microsoft DOS in 1982 without most of the common operating system
functions,
including virtual memory. Over time, however, programmers of personal
computers encountered exactly the same programming problems as their
predecessors in the 1950s, 1960s, and 1970s. That put pressure on the
major PC
operating system makers (Apple, Microsoft, and IBM) to add
multiprogramming
and virtual memory to their operating systems. These makers were able
to
respond positively because the major chip builders had never lost
faith; Intel
offered virtual memory and cache in its 80386 chip in 1985; and
Motorola did
likewise in its 68020 chip. Apple offered multiprogramming in its
MultiFinder
and virtual memory in its System 6 operating system. Microsoft offered
multiprogramming in Windows 3.1 and virtual memory in Windows 95. IBM
offered multiprogramming and virtual memory in OS/2."
and
"From time to time over the past forty years, various people have
argued that
virtual memory is not really necessary because advancing memory
technology
would soon permit us to have all the random-access main memory we
could
possibly want. Such predictions assume implicitly that the primary
reason for
virtual memory is automatic storage allocation of a memory hierarchy.
The
historical record reveals, to the contrary, that the driving force
behind virtual
memory has always been simplifying programs (and programming) by
insulating algorithms from the parameters of the memory configuration
and by
allowing separately constructed objects to be shared, reused, and
protected. The
predictions that memory capacities would eventually be large enough to
hold
everything have never come true and there is little reason to believe
they ever
will. And even if they did, each new generation of users has
discovered that its
ambitions for sharing objects led it to virtual memory. Virtual memory
accommodates essential patterns in the way people use computers. It
will still be
used when we are all gone."
(taken from "Before Memory was Virtual"
http://denninginstitute.com/pjd/PUBS/bvm.pdf
-dai
Bill Gunshannon
Dec 14, 2012, 9:24:21 PM12/14/12
to
In article <aa44300f-ff8f-4440...@a2g2000yqh.googlegroups.com>,
So did I. ASCII, EBCDIC and Field-data.
But that doesn't mean that everyone else did that. Oh, and I have seen
lots of non-portable Fortran in my career.
I have a MAC laptop. It's OK. but I am no more impressed with it than
any other unix box. As for MAC apps, they go out of their way to make
their stuff non-portable. It's a religious thing.
On the unix side I run various falvors of Linux, OpenBSD, NetBSD, FreeBSD,
BSD-2.11, SunOS, SOLARIS, Ultrix-11, Ultrix-32, XENIX, Version7 and I think
there is still a SYSTEM-III floating around. In the past I have also done
IRIX, AIX, DomainIX and, of course, PRIMIX. Guess which one was the only
one that needed major re-writes of even the most trivial of programs to
to make them work. :-)
>> > Someone started a port of gcc to prime ages ago, but even if they ever
>> > finished it, I think it was gcc 1.x, so I doubt you could get much
>> > modern freeware ported to it with ease.
>>
>> Based on personal experience, the biggest problem with porting common
>> unix software to Primos was the ASCII problem. It breaks most parsers
>> which assume values between 0 and 127. And then we have the NULL issue.
>> What do you think the numeric value of NULL under Prime C was? :-)
>> Hint: it certainly wasn't 0. How many programs do you think that breaks?
> Again, this is due to poor design assumptions by the original
> programmer.
> The value of the expression [literal "A" minus literal "@"] is always
> the
> same, whether its on a Prime or on MS-DOS.
Which means nothing when the switch statement looks at chars and assumes
the numeric value is between 0 and 127. I am still waiting for someone
to explain to me just what Prime thought they were accomplishing with
that mark parity stuff. Of course, the native Unix that was never allowed
to be released got rid of it and the 50-series ran just fine without it.
>> > Now, as to APIs.... a universal API was the long-sought Holy Grail of
>> > programming. Guess what? We finally got it. It's called the World Wide
>> > Web.
>>
>> Sorry, that is hardly an API. I work with a lot of systems that have no
>> and will never have access to the "World Wide Web" (whatever that is).
>> Having an API does not mean running Java off the INTERNET.
> The web actually has a number of APIs; of course I really meant to
> say, the
> web is the universal applications platform. I think you can even do
> stuff
> like EDI and CICS via webapps now.
And every different system and OS requires a program to do that. With
a common API the same program could be compiled without modification on
any of them.
Trust me it did. They were often seen as the odd man out. I watched them
loose RFP's even when they outperformed their competitiors (usually a VAX).
One of the problems was, again, all the applications available for Unix
already (many free) that could not even be made to run on PRIMOS. Good
hardware and nice OS are meanngless without the tools to do real work.
And if the tools are rare or have to be totally re-engineered then they
also come with a high price. Strike two.
>> > In most cases, different APIs provide equivalent ways to do things, so
>> > if
>> > you isolate the platform-specific details, you only have to change
>> > them
>> > in one place.
>>
>> If you develop to a common API you don't have to change them at all.
> One's order is another's chaos.
>> > The sole exception to this seems to be how so many *nix
>> > platforms lack a way to check for a keypress without echoing it,
>>
>> Name them. I have never seen such a system and I have been doing Unix
>> for 30 years.
> I misstated that I meant to say, there is no single portable solution
> to
> this. Each system tends to provide its own way. So in fact there is no
> "Unix Way" to check for a keypress, process the keypress if it
> happened,
> but not echo it back out again, unless the program does so itself.
You have to go all the way back to when AT&T was still doing SYS-V
development for that to be true. AT&T did a lot of things different,
deliberately, in order to try and hold onto a market. Remember STREAMS?
Once Berkeley became pretty much the standard everybody did it in a
pretty standard way. And still, there is more than one way. Of course,
if you are running local echo, all bets are off. :-)
>> > to read the key if it was pressed, and act on it accordingly. When I
>> > looked into this recently, I found many people asking the same
>> > question,
>> > how to do it, and most of the *nix world just said "why on earth do
>> > you
>> > want to do that, are you writing a password entry routine, if so, call
>> > <xxx> and you're done."
>>
>> You talk to some very strange unix people. I can think of at least two
>> ways to do this right off the top of my head.
> yes, I misstated the problem. It's doable on every system, but there
> seems
> to be no universal way to do it. Look at the variety offered here:
> http://stackoverflow.com/questions/421860/c-c-capture-characters-from-standard-input-without-waiting-for-enter-to-be-pr
I just took a quick glance and they all seem to be doing ti the same way
with additional coding that appears to be programmer choice rather than
required by the OS. And one was Windows which would have to be different.
>> > I suppose these folks had never written machine emulators that need to
>> > interact with host hardware transparently, in order to let the
>> > emulated
>> > machine's software treat it accordingly.
>>
>> Sorry, I can't even begin to understand what this means.
> If you're writing an machine emulator, and you're going to run an
> operating
> system on it, and that operating system wants to talk to a keyboard,
> and
> do so in either half-duplex (and thus not echo the characters) or in
> full-duplex
> (and thus echo the characters). The decision to echo shouldn't be made
> by the
> runtime library of the language you wrote the emulator in, or the
> operating
> system of the computer that hosts the emulator. The decision needs to
> be made
> by the operating system running on the emulator.
> I hope that's clearer.
Yes, and where is that not the case? Control of character echo is done
by the OS on Unix, not by the C language.
>> >> Nothing wrong with a rant. Especially if it brings out the explanation
>> >> for why something was actually done. Reading Debbie Scherrer's original
>> >> paper would go a long way towards understanding the goals of the project.
>> > I did read it, and I get it, I just disagree with the premise.
>> > The kind of universal API proposed, I find of limited or no value.
>> > But I think it's nonetheless important to find and preserve this
>> > software.
>>
>> Well, I guess the people who reinvented the wqheel to give us POSIX
>> didn't agree with you. :-)
> OS designers have been picking and choosing what bits from POSIX they
> wish to implement. Yes, generally, for whatever portions DO get
> implemented,
> those tend to respond as expected.
That's one flaw in POSIX, but it is politics and not technical. There
is no requirement to do all of it and they even established levels of
compliance. But trying to force an all or nothing deal never works either.
Look at Ada.
> I tend to think another reason it
> works
> well is due to the lack of diversity in processor architectures these
> days.
Well, if your world is limited to PC's, that may be true. But then some
of us still have things like the VAX, Alpha, Itanium, SPARC, M68K and
PDP-11. And then you have the embedded world. 8051, ARM, RM7035C :-)
and heaven only knows how many others.
Cute story, but nothing new to anyone who has been in this business for
more than a decade. And irrelevant to the issue of wether or not a
standard API is useful. :-)
But that doesn't mean that everyone else did that. Oh, and I have seen
lots of non-portable Fortran in my career.
any other unix box. As for MAC apps, they go out of their way to make
their stuff non-portable. It's a religious thing.
On the unix side I run various falvors of Linux, OpenBSD, NetBSD, FreeBSD,
BSD-2.11, SunOS, SOLARIS, Ultrix-11, Ultrix-32, XENIX, Version7 and I think
there is still a SYSTEM-III floating around. In the past I have also done
IRIX, AIX, DomainIX and, of course, PRIMIX. Guess which one was the only
one that needed major re-writes of even the most trivial of programs to
to make them work. :-)
>> > Someone started a port of gcc to prime ages ago, but even if they ever
>> > finished it, I think it was gcc 1.x, so I doubt you could get much
>> > modern freeware ported to it with ease.
>>
>> Based on personal experience, the biggest problem with porting common
>> unix software to Primos was the ASCII problem. It breaks most parsers
>> which assume values between 0 and 127. And then we have the NULL issue.
>> What do you think the numeric value of NULL under Prime C was? :-)
>> Hint: it certainly wasn't 0. How many programs do you think that breaks?
> Again, this is due to poor design assumptions by the original
> programmer.
> The value of the expression [literal "A" minus literal "@"] is always
> the
> same, whether its on a Prime or on MS-DOS.
the numeric value is between 0 and 127. I am still waiting for someone
to explain to me just what Prime thought they were accomplishing with
that mark parity stuff. Of course, the native Unix that was never allowed
to be released got rid of it and the 50-series ran just fine without it.
>> > Now, as to APIs.... a universal API was the long-sought Holy Grail of
>> > programming. Guess what? We finally got it. It's called the World Wide
>> > Web.
>>
>> Sorry, that is hardly an API. I work with a lot of systems that have no
>> and will never have access to the "World Wide Web" (whatever that is).
>> Having an API does not mean running Java off the INTERNET.
> The web actually has a number of APIs; of course I really meant to
> say, the
> web is the universal applications platform. I think you can even do
> stuff
> like EDI and CICS via webapps now.
a common API the same program could be compiled without modification on
any of them.
loose RFP's even when they outperformed their competitiors (usually a VAX).
One of the problems was, again, all the applications available for Unix
already (many free) that could not even be made to run on PRIMOS. Good
hardware and nice OS are meanngless without the tools to do real work.
And if the tools are rare or have to be totally re-engineered then they
also come with a high price. Strike two.
>> > In most cases, different APIs provide equivalent ways to do things, so
>> > if
>> > you isolate the platform-specific details, you only have to change
>> > them
>> > in one place.
>>
>> If you develop to a common API you don't have to change them at all.
> One's order is another's chaos.
>> > The sole exception to this seems to be how so many *nix
>> > platforms lack a way to check for a keypress without echoing it,
>>
>> Name them. I have never seen such a system and I have been doing Unix
>> for 30 years.
> I misstated that I meant to say, there is no single portable solution
> to
> this. Each system tends to provide its own way. So in fact there is no
> "Unix Way" to check for a keypress, process the keypress if it
> happened,
> but not echo it back out again, unless the program does so itself.
development for that to be true. AT&T did a lot of things different,
deliberately, in order to try and hold onto a market. Remember STREAMS?
Once Berkeley became pretty much the standard everybody did it in a
pretty standard way. And still, there is more than one way. Of course,
if you are running local echo, all bets are off. :-)
>> > to read the key if it was pressed, and act on it accordingly. When I
>> > looked into this recently, I found many people asking the same
>> > question,
>> > how to do it, and most of the *nix world just said "why on earth do
>> > you
>> > want to do that, are you writing a password entry routine, if so, call
>> > <xxx> and you're done."
>>
>> You talk to some very strange unix people. I can think of at least two
>> ways to do this right off the top of my head.
> yes, I misstated the problem. It's doable on every system, but there
> seems
> to be no universal way to do it. Look at the variety offered here:
> http://stackoverflow.com/questions/421860/c-c-capture-characters-from-standard-input-without-waiting-for-enter-to-be-pr
with additional coding that appears to be programmer choice rather than
required by the OS. And one was Windows which would have to be different.
>> > I suppose these folks had never written machine emulators that need to
>> > interact with host hardware transparently, in order to let the
>> > emulated
>> > machine's software treat it accordingly.
>>
>> Sorry, I can't even begin to understand what this means.
> If you're writing an machine emulator, and you're going to run an
> operating
> system on it, and that operating system wants to talk to a keyboard,
> and
> do so in either half-duplex (and thus not echo the characters) or in
> full-duplex
> (and thus echo the characters). The decision to echo shouldn't be made
> by the
> runtime library of the language you wrote the emulator in, or the
> operating
> system of the computer that hosts the emulator. The decision needs to
> be made
> by the operating system running on the emulator.
> I hope that's clearer.
by the OS on Unix, not by the C language.
>> >> Nothing wrong with a rant. Especially if it brings out the explanation
>> >> for why something was actually done. Reading Debbie Scherrer's original
>> >> paper would go a long way towards understanding the goals of the project.
>> > I did read it, and I get it, I just disagree with the premise.
>> > The kind of universal API proposed, I find of limited or no value.
>> > But I think it's nonetheless important to find and preserve this
>> > software.
>>
>> Well, I guess the people who reinvented the wqheel to give us POSIX
>> didn't agree with you. :-)
> OS designers have been picking and choosing what bits from POSIX they
> wish to implement. Yes, generally, for whatever portions DO get
> implemented,
> those tend to respond as expected.
is no requirement to do all of it and they even established levels of
compliance. But trying to force an all or nothing deal never works either.
Look at Ada.
> I tend to think another reason it
> works
> well is due to the lack of diversity in processor architectures these
> days.
of us still have things like the VAX, Alpha, Itanium, SPARC, M68K and
PDP-11. And then you have the embedded world. 8051, ARM, RM7035C :-)
and heaven only knows how many others.
more than a decade. And irrelevant to the issue of wether or not a
standard API is useful. :-)
Dennis Boone
Dec 15, 2012, 11:51:55 AM12/15/12
to
> Again, this is due to poor design assumptions by the original
> programmer. The value of the expression [literal "A" minus literal
> "@"] is always the same, whether its on a Prime or on MS-DOS.
Even this expression is dangerous to portability though. In ASCII,
> programmer. The value of the expression [literal "A" minus literal
> "@"] is always the same, whether its on a Prime or on MS-DOS.
the value of that expression is one regardless of parity. But in
EBCDIC, it's 69, and in Display Code it's -59.
(And yes, I know you were talking about Prime parity.)
De
Dennis Boone
Dec 15, 2012, 11:58:57 AM12/15/12
to
> I am still waiting for someone
> to explain to me just what Prime thought they were accomplishing with
> that mark parity stuff.
Originally, retaining compatibility with the Honeywell machines,
> to explain to me just what Prime thought they were accomplishing with
> that mark parity stuff.
the doing of which was part of their original business plan.
The Honeywell machines were that way, iirc, because they were being
compatible with some form of teletype.
Of course once you saddle yourself with a compatibility albatross,
your customers make it hard to dump.
De
matt weber
Dec 16, 2012, 2:28:43 PM12/16/12
to
>
>I don't think Prime's software technology played any role in their
>demise.
the most profitable customers needed. The demand for CPU 'horsepower'
isn't quite like Moore's law, but it is close, figure about 30% per
year. In the 15 years or so between the 750 and the 6450 Prime's
ability to delivery raw CPU speed grew only about 8% per year. Add to
that the 5000 machines were only about half the raw performance that
was announced initially.
Add that to a long list of other R&D projects that failed to deliver
useful products on a timely basis and you have a recipe for disaster.
>Bad business decisions and the LowBlow takeover was what killed them.
>
One of the more telling items was that the ratio of equipment sales
to maintenance revenue kept falling.
I won't dispute that there were more a few bad decisions involved
however...
Daiyu Hurst
Sep 24, 2019, 5:46:58 PM9/24/19
to
From: Arnold Robbins
Date: Tue, Sep 24, 2019 at 1:01 PM
Subject: [TUHS] Recovered!!! The Georgia Tech Software Tools Subsystem for Prime Computers
Hello All.
Believed lost in the mists of time for over 30 years, the Georgia Tech
Software Tools Subsystem for Prime Computers, along with the Georgia Tech
C Compiler for Prime Computers, have been recovered!
The source code and documentation (and binary files) are available in a
Github repo: https://github.com/arnoldrobbins/gt-swt.
The README.md there provides some brief history and credits with respect
to the recovery, and w.r.t. the subsystem and C compilers themselves.
Credit to Scott Lee for making and keeping the tapes and driving the
recovery process, and to Dennis Boone and yours truly for contributing
financially. I set up the repo.
For anyone who used and/or contributed to this software, we hope you'll
enjoy this trip down memory lane.
Feel free to forward this note to interested parties.
Enjoy,
Arnold Robbins
(On behalf of the swt recovery team. :-)
--
X-Clacks-Overhead: GNU Terry Pratchett
Dennis Boone
Sep 25, 2019, 5:10:58 AM9/25/19
to
> Found. I'm surprised Dennis hadn't posted about this already.
Was trying to get docs and downloadable binaries ready to go first. ;)
De
Bill Gunshannon
Sep 25, 2019, 8:43:37 AM9/25/19
to
Prime 50 Series emulator available with Primos? I would love to get
an 850 equivalent running again. I left the Prime world around 19.4
and still miss it.
bill
Daiyu Hurst
Sep 25, 2019, 8:54:11 AM9/25/19
to
Bernard Giroud
Sep 26, 2019, 4:08:21 AM9/26/19
to
Le 25/09/2019 à 14:43, Bill Gunshannon a écrit :
> On 9/25/19 5:10 AM, Dennis Boone wrote:
>> > Found. I'm surprised Dennis hadn't posted about this already.
>>
>> Was trying to get docs and downloadable binaries ready to go first. ;)
>>
>> De
>>
>
>
> [...]. I left the Prime world around 19.4
> On 9/25/19 5:10 AM, Dennis Boone wrote:
>> > Found. I'm surprised Dennis hadn't posted about this already.
>>
>> Was trying to get docs and downloadable binaries ready to go first. ;)
>>
>> De
>>
>
>
> and still miss it.
>
> bill
>
Well said, Bill! Me too. Ah! PL/P and CPL...
>
> bill
>
--
Ne demande ton chemin à personne, tu risquerais de ne plus pouvoir te
perdre. (Rabbin Nahman de Bratslav)
Never ask your way to somebody who knows it, you couldn’t get lost.
(Rabbi Nachman of Breslow)
Daiyu Hurst
Sep 4, 2021, 2:25:14 PM9/4/21
to
On Wednesday, September 25, 2019 at 8:43:37 AM UTC-4, Bill Gunshannon wrote:
As I guess you know by now, the emulator is available for person use. You can in fact start the emulator in a configuration specifying a P850, but I don't think it actually spawns two CPUs.
-Dai
Bill Gunshannon
Sep 10, 2021, 1:48:07 PM9/10/21
to
available, any chance someone has a copy of Primix?
bill
Daiyu Hurst
Sep 10, 2021, 11:39:51 PM9/10/21
to
https://sysovl.info/pages/blobs/prime/brochures/jim/PrimeUNIXos.pdf
But, like Christianity, there's endless proliferation of Unix. Every time two Christians disagree about scripture, they schism, and form two new churches. Likewise with Unix, every time two programmers disagree about how it should work or what services it should provide, someone spawns a new version.
Not quite so many different Multics-like operating systems. Just Multics and Primos, and well, OpenVOS (Stratus).
If there was anything sort of different about Primix, it was that it co-existed with another OS, Primos, operating side-by-side on the same machine. But again, whatever benefits Unix has supposedly provide, like some mythical level-playing field, if you've ever tried building common open-source software packages written in a supposedly-standard language, C (or C++), you end up in configuration and toolchain hell for more time than you ever spend actually running the package you wanted to have on the target hardware.
It may be out there. Before they closed, the Living Computer Museum acquired a LOT a stuff that awaits the end of the pandemic, and the beginning of a renewed interest on the part of the museum's owner. Maybe they have it. But they're closed.
-Dai
Daiyu Hurst
Sep 10, 2021, 11:44:41 PM9/10/21
to
On Thursday, September 26, 2019 at 4:08:21 AM UTC-4, Bernard Giroud wrote:
> Le 25/09/2019 à 14:43, Bill Gunshannon a écrit :
> > On 9/25/19 5:10 AM, Dennis Boone wrote:
> >> > Found. I'm surprised Dennis hadn't posted about this already.
> Le 25/09/2019 à 14:43, Bill Gunshannon a écrit :
> > On 9/25/19 5:10 AM, Dennis Boone wrote:
> >> > Found. I'm surprised Dennis hadn't posted about this already.
> Well said, Bill! Me too. Ah! PL/P and CPL...
And full PL/I and SPL and PL/1G. And C. And more:
OK, OPR 1 /* SHARE REQUIRES OPR 1
OK, SHARE PRIRUN>ASRPATCH 6
OK, SHARE 6 700
OK, SHARE 7 700
OK, SHARE SYSTEM>ED2000 2000 /* SHARE the editor - ED
OK, SHARE 2014
OK, CO SYSTEM>COBOL.SHARE.COMI 7 /* share COBOL
OK, /* COBOL.SHARE.COMI, COBOL, JPC-RHB, 04/01/80
OK, /* shares COBOL compiler and library
OK, /* Copyright (C) 1980, Prime Computer, Inc., Wellesley, MA 02181
OK, /*
OK, OPR 1
OK, SHARE SYSTEM>C2014A 2014 700
OK, SHARE SYSTEM>C2014B 2014 700
OK, R SYSTEM>C4000 1/3
THIS IS PACKAGE #03
OK, SHARE SYSTEM>CO2016 2016
OK, SHARE 2014
OK, OPR 0
OK, CO -CONTINUE 6
OK, CO SYSTEM>SPL.SHARE.COMI 7 /* share SPL
OK, /* SPL.SHARE.COMI, INDEX>SPL, KJC, 01/06/83
OK, /* Share SPL system
OK, /* Copyright (c) 1981, Prime Computer, Inc., Natick, MA 01760
OK, Opr 1
OK, /* First share the Compiler
OK, Share system>sp2116 2116
OK, Share system>sp2117 2117
OK, Share system>sp2120 2120
OK, /* Now share the Runtime support
OK, Share system>sp2121 2121
OK, Resume system>sp4000 1/10
THIS IS PACKAGE #08
OK, Opr 0
OK, Co -continue 6
OK, CO SYSTEM>PLP.SHARE.COMI 7 /* share PLP
OK, /* PLP.SHARE.COMI, INDEX>PLP, KGF, 03/08/81
OK, /* ROUTINE TO SHARE PLP COMPILER
OK, /* COPYRIGHT (C) 1981, PRIME COMPUTER INC., NATICK, MA 01760 */
OK, OPR 1
OK, SHARE SYSTEM>PL2022 2022
OK, SHARE SYSTEM>PL2023 2023
OK, OPR 0
OK, CO -CONTINUE 6
OK, SHARE SYSTEM>ML2222 2222 /* SHARE MAGLIB
OK, R SYSTEM>ML4000
THIS IS PACKAGE #01
OK, /* SHARE SYSTEM>S$2167 2167 /* SHARE SPOOLER LIBRARIES
OK, /* R SYSTEM>S$4000
OK, SHARE 2020 700
OK, CO SYSTEM>BASICV.SHARE.COMI 7 /* share BASICV
OK, /* BASICV.SHARE.COMI, BASICV, JPC, 04/01/80
OK, /* shares BASICV pure code in segment 2013
OK, /* Copyright (C) 1980, Prime Computer, Inc., Wellesley, MA 02181
OK, /*
OK, OPR 1
OK, SHARE SYSTEM>BA2013 2013
OK, OPR 0
OK, CO -CONTINUE 6
OK, CO SYSTEM>CC.SHARE.COMI 7 /* share CC
OK, /* CC.SHARE.COMI, CC, GARTH CONBOY, 08/01/83
OK, /* Share the V and IX mode C compilers.
OK, /* Copyright (c) 1983, Prime Computer, Inc., Natick, MA 01760
OK, /* All Rights Reserved
OK, /*
OK, opr 1
OK, share system>cc2324 2324
OK, share system>cc2325 2325
OK, share system>cc2326 2326
OK, share system>cc2327 2327
OK, opr 0
OK, /*
OK, co -continue 6
OK, CO SYSTEM>EMACS.SHARE.COMI 7
OK, /* EMACS.SHARE.COMI, EMACS, EMACS DEVELOPMENT, 06/16/87
OK, /* Share EMACS.
OK, /* Copyright (C) 1981, Prime Computer Inc., Natick, Ma 01760
OK, /*
OK, /*
OK, /* Modification history:
OK, /*
OK, /* Date Engineer Modification
OK, /* 06/16/87 Bugos Modified to share EM2346.
OK, /* 04/21/84 Rand Modified to share non-snapped EMACS.
OK, /*
OK, /*
OK, OPR 1
OK, /*
OK, SHARE SYSTEM>EM2341 2341 700
OK, SHARE SYSTEM>EM2342 2342 700
OK, SHARE SYSTEM>EM2343 2343 700
OK, SHARE SYSTEM>EM2344 2344 700
OK, SHARE SYSTEM>EM2345 2345 700
OK, SHARE SYSTEM>EM2346 2346 700
OK, SHARE SYSTEM>EM2347 2347 700
SLAVE$ (user 28) logged in Friday, 10 Sep 21 23:00:44.
OK, /*
OK, R SYSTEM>EM4000 1/7
THIS IS PACKAGE #07
OK, /*
OK, EMACS -INITIALIZE_EMACS SYSTEM>INIT_EMACS.EFASL
SLAVE$ (user 29) logged in Friday, 10 Sep 21 23:00:44.
SLAVE$ (user 30) logged in Friday, 10 Sep 21 23:00:44.
SLAVE$ (user 27) logged in Friday, 10 Sep 21 23:00:44.
SLAVE$ (user 26) logged in Friday, 10 Sep 21 23:00:44.
dynamic library segment #3200
dynamic library segment #3201
dynamic library segment #3202
dynamic library segment #3203
dynamic library segment #3204
dynamic library segment #3205
Top of library segment: 3200(3)/177776
Top of library segment: 3201(3)/177777
Top of library segment: 3202(3)/177775
Top of library segment: 3203(3)/177777
Top of library segment: 3204(3)/177775
Top of library segment: 3205(3)/52555
OK, REMEPF EMACS.RUN
OK, /*
OK, SHARE 2341
OK, SHARE 2342
OK, SHARE 2343
OK, SHARE 2344
OK, SHARE 2345
OK, SHARE 2346
OK, SHARE 2347
OK, /*
OK, OPR 0
OK, /*
OK, /* End of file EMACS.SHARE.COMI
OK, /*
OK, CO -CONTINUE 6
OK, /* CO SYSTEM>PL1G.SHARE.COMI 7 /* This looks like it works but doesn't
OK, /* need to do manually after boot
OK, CO SYSTEM>DBG.SHARE.COMI 7 /* share source-level debugger
OK, /* DBG.SHARE.COMI, DBG, JPC-LE, 06/15/90
OK, /* shares DBG
OK, /* Copyright (C) 1980, Prime Computer, Inc., Wellesley, MA 02181
OK,
/* 04/01/80 jpc: initial coding
OK, /* 08/13/85 le: segment 2576 added
OK, /* 06/15/90 srh: segment 2665 added
OK, opr 1
OK, share system>db2040 2040
OK, share system>db2041 2041
OK, share system>db2042 2042
OK, share system>db2115 2115
OK, share system>db2576 2576
OK, share system>db2665 2665
OK, opr 0
OK, co -continue 6
OK, STI -TZ -0500 -DLST YES /* SET_TIME_INFO
OK, OPR 0
OK, START_NET PRIMENET*>PRIMENET.CONFIG -NODE Shadow
[START_NET Rev. 22.1.4 Copyright (c) 1990, Prime Computer, Inc.]
Beginning Network Initialization.
File: PRIMENET*>PRIMENET.CONFIG Rev. 6
(Config_Net rev. 21.0)
*** Node: SHADOW ***
NETMAN (user 34) logged in Friday, 10 Sep 21 23:00:56.
System NOT configured with maximum possible memory.
65536K bytes are available.
32768K bytes memory in use.
2492K bytes are wired.
RMS_PROCESS (user 48) logged out Friday, 10 Sep 21 23:00:56.
Time used: 00h 00m connect, 00m 24s CPU, 00m 00s I/O.
******** RING DISABLED: NO PNC ********
Phantom 48: Normal logout at 23:00
Time used: 00h 00m connect, 00m 24s CPU, 00m 00s I/O.
Primenet Initialization Complete.
OK, CAB -LINE 0 -TO 14 -IBS 1024 -OBS 4096 -DMQS 255
[CAB Rev. 23.4 Copyright (c) 1993, Computervision Corporation]
ISC_NETWORK_SERVER (user 49) logged in Friday, 10 Sep 21 23:01:00.
OK, CAB -REMBUF -IBS 2048 -OBS 4096
[CAB Rev. 23.4 Copyright (c) 1993, Computervision Corporation]
OK, COMO -E
Bill Gunshannon
Sep 11, 2021, 6:16:35 PM9/11/21
to
On 9/10/21 11:39 PM, Daiyu Hurst wrote:
> On Friday, September 10, 2021 at 1:48:07 PM UTC-4, Bill Gunshannon wrote:
>> On 9/4/21 2:25 PM, Daiyu Hurst wrote:
>>> On Wednesday, September 25, 2019 at 8:43:37 AM UTC-4, Bill Gunshannon wrote:
>
>> Just out of curiosity, now that an emulator and versions of Primos are
>> available, any chance someone has a copy of Primix?
>
> There's a brochure:
>
> https://sysovl.info/pages/blobs/prime/brochures/jim/PrimeUNIXos.pdf
>
> But, like Christianity, there's endless proliferation of Unix. Every time two Christians disagree about scripture, they schism, and form two new churches. Likewise with Unix, every time two programmers disagree about how it should work or what services it should provide, someone spawns a new version.
Just what do you consider a "new" version of Unix? There is BSD and
> On Friday, September 10, 2021 at 1:48:07 PM UTC-4, Bill Gunshannon wrote:
>> On 9/4/21 2:25 PM, Daiyu Hurst wrote:
>>> On Wednesday, September 25, 2019 at 8:43:37 AM UTC-4, Bill Gunshannon wrote:
>
>> Just out of curiosity, now that an emulator and versions of Primos are
>> available, any chance someone has a copy of Primix?
>
> There's a brochure:
>
> https://sysovl.info/pages/blobs/prime/brochures/jim/PrimeUNIXos.pdf
>
> But, like Christianity, there's endless proliferation of Unix. Every time two Christians disagree about scripture, they schism, and form two new churches. Likewise with Unix, every time two programmers disagree about how it should work or what services it should provide, someone spawns a new version.
SystemV. That's all there has been for decades. All there will be
going into the future. Implementation on different hardware does not
constitute a "new" version of Unix.
And I left Linux out because it is not now and never has be Unix.
>
> Not quite so many different Multics-like operating systems. Just Multics and Primos, and well, OpenVOS (Stratus).
>
> If there was anything sort of different about Primix, it was that it co-existed with another OS, Primos, operating side-by-side on the same machine.
> But again, whatever benefits Unix has supposedly provide, like some mythical level-playing field, if you've ever tried building common open-source software packages written in a supposedly-standard language, C (or C++), you end up in configuration and toolchain hell for more time than you ever spend actually running the package you wanted to have on the target hardware.
versions. Even back in the days when there were a lot more
incompatibilities between differnt flavors of Unix. But then you have
Primix. A version that can not use any of the common open-source
packages of its day. Sadly, the only thing it actually accomplished
was the have Prime quash the native mode Unix that was being made for
the 50 Series machines. Who knows, that might even have kept Prime in
the market, but, alas, they had no vision. :-)
>
> It may be out there. Before they closed, the Living Computer Museum acquired a LOT a stuff that awaits the end of the pandemic, and the beginning of a renewed interest on the part of the museum's owner. Maybe they have it. But they're closed.
solution for any real problem because it was buried under some
of the worst of Prime's idiosyncrasies.
bill
Daiyu Hurst
Oct 5, 2021, 11:54:04 PM10/5/21
to
On Saturday, September 11, 2021 at 6:16:35 PM UTC-4, Bill Gunshannon wrote:
> On 9/10/21 11:39 PM, Daiyu Hurst wrote:
> > On Friday, September 10, 2021 at 1:48:07 PM UTC-4, Bill Gunshannon wrote:
> >> On 9/4/21 2:25 PM, Daiyu Hurst wrote:
> >>> On Wednesday, September 25, 2019 at 8:43:37 AM UTC-4, Bill Gunshannon wrote:
> > But, like Christianity, there's endless proliferation of Unix. Every time two Christians disagree about scripture, they schism, and form two new churches.
Likewise with Unix, every time two programmers disagree about how it should work or what services it should provide, someone spawns a new version.
> Just what do you consider a "new" version of Unix? There is BSD and
> SystemV. That's all there has been for decades. All there will be
> going into the future. Implementation on different hardware does not
> constitute a "new" version of Unix.
>
> And I left Linux out because it is not now and never has be Unix.
I just got back from the doctor, had to get a truss to hold everything together from nearly laughing myself to death.
> On 9/10/21 11:39 PM, Daiyu Hurst wrote:
> > On Friday, September 10, 2021 at 1:48:07 PM UTC-4, Bill Gunshannon wrote:
> >> On 9/4/21 2:25 PM, Daiyu Hurst wrote:
> >>> On Wednesday, September 25, 2019 at 8:43:37 AM UTC-4, Bill Gunshannon wrote:
> > But, like Christianity, there's endless proliferation of Unix. Every time two Christians disagree about scripture, they schism, and form two new churches.
Likewise with Unix, every time two programmers disagree about how it should work or what services it should provide, someone spawns a new version.
> Just what do you consider a "new" version of Unix? There is BSD and
> SystemV. That's all there has been for decades. All there will be
> going into the future. Implementation on different hardware does not
> constitute a "new" version of Unix.
>
> And I left Linux out because it is not now and never has be Unix.
Of course Linux is Unix. It's nothing but the latest flavor of the same mad rebellion to Multics.
0 new messages