Purely historic question: VT200 text graphic programming

[GrayShark]

On Fri, 11 Mar 2011 15:58:20 +0000, Grant Edwards wrote:

> On 2011-03-11, Anssi Saari <as at sci.fi> wrote:
>> Grant Edwards <invalid at invalid.invalid> writes:
>>
>>> C wasn't very widely used under VMS, and VMS had it's own screen
>>> formatting and form handling libraries.
>>
>> Just curious, what language was widely used in VMS?
> 
> From what I remember, FORTRAN what probably the most popular.  Pascal
> was also well supported and somewhat widely used (especially in
> academia).  Then there was BLISS-32 for the low-level stuff.  C seemed
> to be an afterthought and had a very "kludged" feel to it.  VMS's file
> I/O didn't correspond very will with the C byte stream model, and C's
> view of line-termination didn't play well with everything else.
> 
>> My VMS experience is limited to running Maple for a math course in the
>> university in early 1990s. Didn't know how to do much more than start
>> Maple, probably just dir, logout (or was it logoff?) and ftp :)

I don't remember much of any language being that portable. I do remember 
it was very easy to take DEC Fortran and compile it without much issue on 
SGI/Irix. Much more scary was a program converted to C from Fortran (there 
were precompiler for that) ran slow on Irix then straight Fortran. 

That was godsend for simulation engineers.

I agree, VAX/VMS's i/o model was slow in C. In fortran it was fast as they 
did all the opens when the program started, regardless of where the open 
statement was in the code. I even had a legacy program, open and close a 
file in a subroutine (a no no) that ran fast; debugging code. DEC fortran 
only opened the file once. Had some way of deciding if a write was an 
overwrite or an append. The program ran fast as 'normal' (that being 
without the open and close).

When I ported the program to an Moto 88000 daughter processor board, the 
program ran slow as hell. The 88000 board used a Fortran->C compiler, that 
obeyed the open and close statements. Each time the program ran that 
subroutine, It opened, then closed a log file. Each statement required the 
daughter board to call, via the q-bus, the host OS (VMS), stop, wait for 
VMS to open a file, continue, then stop, wait for VMS to close the file.

The correction was easy, get rid of the legacy debug code. The coder had 
never used the debugger program or a profiler; amazing! Well after both, 
debugging code removed and a run through a profile, the code ran fast as 
hell. 20 sims in the time the microvax III did one. That was probably the 
only reason we didn't move off VAX/VMS (that and old programmer inertia).

Inertia, friend and foe.

Otherwise I worked with a host of government contractors, each with their 
own version of C; each used their specialized version to prevent tax payer 
contracts from going to another contractor.

Thank goodness for standardization. Finally the DOD could drop CSC or EDS 
over priced contracts to maintain code. Unfortunately, could, should and 
did don't have the same meaning at the end of the day.

GrayShark.