On Sun, 11 Aug 2019 11:54:03 -0400, Dennis Lee Bieber wrote:

> On Sat, 10 Aug 2019 17:00:49 -0000 (UTC), Martin Gregorie
>  declaimed the following:
>
>
>>An interesting read: thanks. I've done little to no development using
>>NT,
>>though I did a project or two using VAX VMS and DEC's database RDB.
>>
>>
>  VMS was much better documented. Something like three/four feet of
3"
> thick 3-ring binders. Think there were two or three binders just for the
> SYS$ system calls, another for RMS$ (record management services).
> Manuals for each compiler...
>
>  Try finding that stuff for M$ -- it's a pain, often scattered
about.
> ("Programming Windows 6th Ed" focused on Win8 "Apps" using C#; the
> "Windows Internals" books describe how the OS works, but don't really
> provide anything on the Win32 system calls themselves).
>
>>The main things I remember about VMS were not much liking the concept of
>>having a few massive utility programs and that noticing that there were
>>a
>
>  I don't recall those...
>
They were basically surprisingly large programs, each with a sort of mini-
shell worked interactively. This tended to be quite noticeable - and
could be hard to work round in command scripts, though probably not a big
issue if they were being used interactively. IIRC there was one for file
management. I thought this was odd, the more so as every other OS I'd
used up to then (Georges 1,2 and 3, Flex, DOS, UniFlex and VOS) had a
recognisably separate command line interpreter and a whole bunch of
separate commands, though not always as clearly separated out as they are
in Unix/Linux.

> At least I could make sense of the compiler options since compile and
> link were separate (and, in practice, we would stuff object files into
> a library so the link statement basically referenced just the main
> function and the library as a whole)... Unlike the common invocation of
> "gcc" which attempts to do everything via one command invocation.
>
Almost every compilation system I've used has split out compiling and
linking as separate operations and some have separated the preprocessor
from the compiler. The PLAN assembler (ICL 1900) had a preprocessor with
a syntactically different language which was powerful enough to let you
define your own special purpose languages - rather like using yacc+lex as
a front end for C, Coco/R as a front-end for Java or the IDMS database
preprocessor as front-end for COBOL.

OTOH I've never needed to separate the C preprocessor from its compiler
phase since its so much an integral part of C. WQhen you come to
languages like Algol 68 the whole thing is so self-referential that
everything is rolled into a single compilation executable with no real
distinction made between the code you're working on and the standard
prelude and project-defined modes, operators and functions which together
define the compilation environment.

On top of that, a lot of languages / compilation systems have an
equivalent of C's 'make' - there are two for Java (ant and maven) - and
IMO anyway, are nearly essential for developing any program thats big
enough that splitting it into a set of source files simpifies its
development.

Please don't lets get onto IDEs: I like make and ant a lot but am not
particularly fond of IDEs - I've used the Borland C IDE and IntelliJ for
Java fairly intensively and decided I'm a lot happier using my favourite
editor plus, depending on the language being written, using its
equivalent of 'make' to manage the compilation process.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05