Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.prime > #119 > unrolled thread

Georgia Tech Software Tools for Primos

Started byEdward Feustel <efeustel@hughes.net>
First post2012-11-30 09:47 -0500
Last post2012-12-13 17:22 -0800
Articles 20 on this page of 34 — 9 participants

Back to article view | Back to comp.sys.prime

Contents

  Georgia Tech Software Tools for Primos Edward Feustel <efeustel@hughes.net> - 2012-11-30 09:47 -0500
    Re: Georgia Tech Software Tools for Primos Al Kossow <aek@bitsavers.org> - 2012-11-30 09:28 -0800
      Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-11-30 22:11 -0800
        Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-02 10:54 -0800
          Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 15:01 -0800
            Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 15:03 -0800
            Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-13 23:14 +0000
              Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 17:19 -0800
            Re: Georgia Tech Software Tools for Primos Al Kossow <aek@bitsavers.org> - 2012-12-13 16:11 -0800
            Re: Georgia Tech Software Tools for Primos drb@ihatespam.msu.edu (Dennis Boone) - 2012-12-13 19:57 -0600
              Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 20:55 -0800
                Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-14 13:07 +0000
                  Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-14 08:02 -0800
                    Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-14 17:11 +0000
                      Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-14 17:41 -0800
                        Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-15 02:24 +0000
                          Re: Georgia Tech Software Tools for Primos drb@ihatespam.msu.edu (Dennis Boone) - 2012-12-15 10:58 -0600
                        Re: Georgia Tech Software Tools for Primos drb@ihatespam.msu.edu (Dennis Boone) - 2012-12-15 10:51 -0600
                        Re: Georgia Tech Software Tools for Primos matt weber <mattheww50@verizon.net> - 2012-12-16 14:28 -0500
                  Re: Georgia Tech Software Tools for Primos Andreas Eder <andreas_eder@gmx.net> - 2012-12-14 17:08 +0100
                    Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-14 17:20 +0000
              Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-14 12:52 +0000
      Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2019-09-24 14:46 -0700
        Re: Georgia Tech Software Tools for Primos drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-25 04:10 -0500
          Re: Georgia Tech Software Tools for Primos Bill Gunshannon <bill.gunshannon@gmail.com> - 2019-09-25 08:43 -0400
            Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2019-09-25 05:54 -0700
            Re: Georgia Tech Software Tools for Primos Bernard Giroud <bgiroud3@free.fr> - 2019-09-26 10:08 +0200
              Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2021-09-10 20:44 -0700
            Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2021-09-04 11:25 -0700
              Re: Georgia Tech Software Tools for Primos Bill Gunshannon <bill.gunshannon@gmail.com> - 2021-09-10 13:48 -0400
                Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2021-09-10 20:39 -0700
                  Re: Georgia Tech Software Tools for Primos Bill Gunshannon <bill.gunshannon@gmail.com> - 2021-09-11 18:16 -0400
                    Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2021-10-05 20:54 -0700
    Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 17:22 -0800

Page 1 of 2  [1] 2  Next page →

#119 — Georgia Tech Software Tools for Primos

FromEdward Feustel <efeustel@hughes.net>
Date2012-11-30 09:47 -0500
SubjectGeorgia Tech Software Tools for Primos
Message-ID<3jhhb8hr7rgfptrgb1s083jvrre2ntjc1p@4ax.com>
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

[toc] | [next] | [standalone]

#120

FromAl Kossow <aek@bitsavers.org>
Date2012-11-30 09:28 -0800
Message-ID<k9aqco$qn$1@dont-email.me>
In reply to#119
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.

[toc] | [prev] | [next] | [standalone]

#122

FromDaiyu Hurst <daiyu.hurst@gmail.com>
Date2012-11-30 22:11 -0800
Message-ID<71944a09-53ef-4256-b95a-a949a0349dfc@b9g2000pba.googlegroups.com>
In reply to#120
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 [spaf@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!

[toc] | [prev] | [next] | [standalone]

#129

FromDaiyu Hurst <daiyu.hurst@gmail.com>
Date2012-12-02 10:54 -0800
Message-ID<ebd22ed3-1f9b-459a-9f80-632156289808@me7g2000pbb.googlegroups.com>
In reply to#122
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
> 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...
>
> All kinds of stuff keeps turning up that was long thought lost. Have
> hope!

Ok, correction, Phil Enslow at Georgia Institute of Technology, was
who I
was corresponding with.

-dai

[toc] | [prev] | [next] | [standalone]

#144

FromDaiyu Hurst <daiyu.hurst@gmail.com>
Date2012-12-13 15:01 -0800
Message-ID<655bf127-e26a-4265-8e3a-5f142b4567d6@f8g2000yqa.googlegroups.com>
In reply to#129
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.

                        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

[toc] | [prev] | [next] | [standalone]

#145

FromDaiyu Hurst <daiyu.hurst@gmail.com>
Date2012-12-13 15:03 -0800
Message-ID<f9c58602-ab6c-451b-a8b7-6c7b2472280b@u19g2000yqj.googlegroups.com>
In reply to#144
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:

https://docs.google.com/open?id=0ByJs3HoO8aRVd1JlOGJWRlJhTDg

-dai

[toc] | [prev] | [next] | [standalone]

#146

Frombillg999@cs.uofs.edu (Bill Gunshannon)
Date2012-12-13 23:14 +0000
Message-ID<aiv5qlFa7qqU2@mid.individual.net>
In reply to#144
In article <655bf127-e26a-4265-8e3a-5f142b4567d6@f8g2000yqa.googlegroups.com>,
	Daiyu Hurst <daiyu.hurst@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.
>                         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

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
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

[toc] | [prev] | [next] | [standalone]

#148

FromDaiyu Hurst <daiyu.hurst@gmail.com>
Date2012-12-13 17:19 -0800
Message-ID<49622f6b-835c-4e34-b0b9-5059fe2c9280@10g2000yqk.googlegroups.com>
In reply to#146
On Dec 13, 6:14 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> 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.

>
> 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
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

[toc] | [prev] | [next] | [standalone]

#147

FromAl Kossow <aek@bitsavers.org>
Date2012-12-13 16:11 -0800
Message-ID<kadqqr$v98$1@dont-email.me>
In reply to#144
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.
Document scans are up under
http://bitsavers.org/pdf/georgiaTech

[toc] | [prev] | [next] | [standalone]

#150

Fromdrb@ihatespam.msu.edu (Dennis Boone)
Date2012-12-13 19:57 -0600
Message-ID<C4Odnaszi4oAGlfNnZ2dnUVZ_vCdnZ2d@giganews.com>
In reply to#144
 > 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_Subsystem_Users_Guide_4ed_May85.pdf

De

[toc] | [prev] | [next] | [standalone]

#151

FromDaiyu Hurst <daiyu.hurst@gmail.com>
Date2012-12-13 20:55 -0800
Message-ID<badcca16-ee32-499e-b50e-0d1e5f1d7436@j4g2000yqh.googlegroups.com>
In reply to#150
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.

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.

[toc] | [prev] | [next] | [standalone]

#154

Frombillg999@cs.uofs.edu (Bill Gunshannon)
Date2012-12-14 13:07 +0000
Message-ID<aj0mjkFkq7aU2@mid.individual.net>
In reply to#151
In article <badcca16-ee32-499e-b50e-0d1e5f1d7436@j4g2000yqh.googlegroups.com>,
	Daiyu Hurst <daiyu.hurst@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.

> 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.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

[toc] | [prev] | [next] | [standalone]

#155

FromDaiyu Hurst <daiyu.hurst@gmail.com>
Date2012-12-14 08:02 -0800
Message-ID<1b811bb7-a9e0-4efb-9e9c-a493e97833a9@b8g2000yqh.googlegroups.com>
In reply to#154
On Dec 14, 8:07 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> 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
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

[toc] | [prev] | [next] | [standalone]

#158

Frombillg999@cs.uofs.edu (Bill Gunshannon)
Date2012-12-14 17:11 +0000
Message-ID<aj14trFntonU1@mid.individual.net>
In reply to#155
In article <1b811bb7-a9e0-4efb-9e9c-a493e97833a9@b8g2000yqh.googlegroups.com>,
	Daiyu Hurst <daiyu.hurst@gmail.com> writes:
> On Dec 14, 8:07 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
>> 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
> 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.

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.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

[toc] | [prev] | [next] | [standalone]

#161

FromDaiyu Hurst <daiyu.hurst@gmail.com>
Date2012-12-14 17:41 -0800
Message-ID<aa44300f-ff8f-4440-905c-3040c03dae31@a2g2000yqh.googlegroups.com>
In reply to#158
On Dec 14, 12:11 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
> 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
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

[toc] | [prev] | [next] | [standalone]

#163

Frombillg999@cs.uofs.edu (Bill Gunshannon)
Date2012-12-15 02:24 +0000
Message-ID<aj25akFdikU1@mid.individual.net>
In reply to#161
In article <aa44300f-ff8f-4440-905c-3040c03dae31@a2g2000yqh.googlegroups.com>,
	Daiyu Hurst <daiyu.hurst@gmail.com> writes:
> On Dec 14, 12:11 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
>> 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
> 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.

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.

>> > 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.

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.

>> > 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.

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.

>> > 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

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.  :-)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

[toc] | [prev] | [next] | [standalone]

#165

Fromdrb@ihatespam.msu.edu (Dennis Boone)
Date2012-12-15 10:58 -0600
Message-ID<BPSdnccZIdHMMVHNnZ2dnUVZ_gOdnZ2d@giganews.com>
In reply to#163
 >                                          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,
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

[toc] | [prev] | [next] | [standalone]

#164

Fromdrb@ihatespam.msu.edu (Dennis Boone)
Date2012-12-15 10:51 -0600
Message-ID<XNudnVUSZ402N1HNnZ2dnUVZ_qGdnZ2d@giganews.com>
In reply to#161
 > 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,
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

[toc] | [prev] | [next] | [standalone]

#166

Frommatt weber <mattheww50@verizon.net>
Date2012-12-16 14:28 -0500
Message-ID<fo7sc85qog4agsu3hbbsdam9di80mucttr@4ax.com>
In reply to#161
>
>I don't think Prime's software technology played any role in their
>demise.
What did Prime in was the inability to deliver the performance that
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.
>
Prime was in serious trouble long before LeBeau appeared on the scene.
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...

[toc] | [prev] | [next] | [standalone]

#157

FromAndreas Eder <andreas_eder@gmx.net>
Date2012-12-14 17:08 +0100
Message-ID<877gokvcp9.fsf@eder.homelinux.net>
In reply to#154
>>>>> "Bill" == Bill Gunshannon <billg999@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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.prime

csiph-web