This makes sense since there was B runtime to start, and Dennis was messing with things. No idea but I wonder if that was the impetus for the rename from B to newB to C - when he introduced a new runtime? ᐧ On Mon, Jun 12, 2023 at 2:30 PM Dan Cross <crossd(a)gmail.com> wrote:

I had thought that crt stood for “compiler runtime”. You’ll find files on a NetBSD (and other BSDs) in /usr/lib/csu called crt0, crtbegin, crtend (etc) which are included in the compiled binaries at build time and are used to include machine dependent things need to initialise programs. (The acronym could be wrong of course - bss is the notorious one, where even the man page for a.out has this has a bug: "Nobody seems to agree on what bss stands for.”) C

Possibly - in this file http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/README?rev=1.6&content-…tag=MAIN, the CSU and related files are referred to as the compiler runtime. But startoff is appropriate - because the file was usually included in the binary at the beginning to initialise stuff. These days ELF formats and similar have specific sections for initing and terminating binaries - although I the crt name lives on with start and end: servalan: {482} ls -la /usr/lib/crt* -r--r--r-- 1 root wheel 4328 Jan 14 18:18 /usr/lib/crt0.o -r--r--r-- 1 root wheel 2648 Jan 14 18:18 /usr/lib/crtbegin.o -r--r--r-- 1 root wheel 2880 Jan 14 18:18 /usr/lib/crtbeginS.o lrwxr-xr-x 1 root wheel 10 Jan 14 18:18 /usr/lib/crtbeginT.o -> crtbegin.o -r--r--r-- 1 root wheel 1264 Jan 14 18:18 /usr/lib/crtend.o lrwxr-xr-x 1 root wheel 8 Jan 14 18:18 /usr/lib/crtendS.o -> crtend.o -r--r--r-- 1 root wheel 1488 Jan 14 18:18 /usr/lib/crti.o -r--r--r-- 1 root wheel 1152 Jan 14 18:18 /usr/lib/crtn.o I wrote a paper on a.out a year or so ago and concluded that I could not find an adequate answer - so avoided the issue with a non-commital footnote. C

I don't know about this, only given the fact that B was already there and had a brt1 and brt2, crt0 seems like a natural follow-on to this naming scheme and I would suspect the c in crt0 referring to the language, not "compiler" was probably there from the genesis. These are the single letter associations I've found: - a - assembly as in liba.a - b - B lang as in libb.a, brt1, bilib - c - C lang as in libc.a, crt0 - e - Explor as in libe.a - f - Fortran as in fc, f77, libf.a, fr0 - l - LIL as in lc (LIL compiler) - m - m6 as in /sys/lang/mdir Of course letters get reused for things, this logic would imply the LIL language would have a libl.l but that instead is the lex library as appears a little later on. Y of course eventually gets associated with yacc. Not affirmative proof but I would be more inclined to suspect the c there is a language reference than standing for "compiler" - Matt G. P.S. The "bss" definition that lives in my head is "block-sized storage" but frankly I can't recall where I picked that up. I feel like I didn't just make that up but Google returns nothing.

On Mon, 12 Jun 2023, Chris Pinnock via TUHS wrote: I always understood crt to stand for "C runtime". -uso.

On Mon, Jun 12, 2023 at 4:17 PM Dave Horsfall <dave(a)horsfall.org> wrote: crt - C RunTme. I always heard it expressed as C runtime SYSTEM or START WRT to BSS -- Block Start Symbol (and sometimes Block End Symbol in some later assemblers) I believe was (were) part of the original 704 assemblers from United Aircraft reserving a labeled block of uninitialized space in a "DUMMY SECTION" (or DSECT) for a hunk of storage. The OS is going to load everything together. So, a big feature of the United Aircraft assembler was to help control memory layout and collect like (common) hunks of things together (i.e., code vs data). The whole idea of BSS was to get the loader to reserve space that did not have to initialized. As I understand it, the standard IBM FORTRAN (FAP) and Assembler (MAP) for the 709 and 7090/94 picked it up, with the new FORTRAN compiler being the big driver. ᐧ

Apologies to TUHS - other than please don't think Fortran did not impact UNIX and its peers. We owe that community our jobs, and for creating the market in that we all would build systems and eventually improve. Note: I'm CCing COFF - you want to continue this... On Mon, Jun 12, 2023 at 5:39 PM G. Branden Robinson < g.branden.robinson(a)gmail.com&gt; wrote: Be careful there, weedhopper ... Fortran gave a lot to computing (including UNIX) and frankly still does. I did not write have too much Fortran as a professional (mostly early in my career), but I did spent 50+ years ensuring that the results of the Fortran compiler ran >>really well<< on the systems I built. As a former collegiate of Paul W and I once said, "*Any computer executive that does not take Fortran seriously will not have their job very long.* It pays our salary." It's still the #1 language for science [its also not the same language my Father learned in the late 50s/early 60s, much less the one I learned 15 years later - check out: In what type of work is the Fortran Programming Language most used today <https://www.quora.com/In-what-type-of-work-is-the-Fortran-programming-language-most-used-today/answer/Clem-Cole> , Is Fortran still alive <https://www.quora.com/Is-Fortran-still-alive/answer/Clem-Cole>, Is Fortran obsolete <https://www.quora.com/Is-Fortran-obsolete/answer/Clem-Cole> FWIW: These days, the Intel Fortran compiler (and eventually the LLVM one, which Intel is the primary developer), calls the C/C++ common runtime for support. Most libraries are written in C, C++, (or assembler in some very special cases) - so now it's C that keeps Fortran alive. But "in the beginning" it was all about Fortran because that paid the bills then and still does today. ᐧ

On 6/12/23, Clem Cole &lt;clemc(a)ccc.com&gt; wrote: I don't think this remark was intended to denigrate Fortran in any way. I took it as a wryly humorous way to make the observation that C and Fortran have different program startup semantics, and that there is other stuff that has to be done when firing up a program written wholly or partially in Fortran beyond what is needed to start up a C application. Most operating system ABIs, Unix included, don't have a formalized mechanism for dealing with the differences between startup semantics of various programming languages. They deal with the problem in an ad-hack fashion. The one exception that I know of is VMS (now OpenVMS). Tom Hastings was the architect who designed the original VAX/VMS ABI. He was aware from the get-go that several programming languages had to be supported and he made sure that his design was general enough to allow programmers to write routines in the most suitable language for them, to mix and match modules written in different languages in the same program, and to easily make calls from one language to another. It was a stroke of genius and I haven't seen its like in any other OS (several times I've wished it was there, though). Further discussion in COFF. -Paul W.

On Mon, 12 Jun 2023, Clem Cole wrote: Ah; well, I was almost right :-) It's been a while since I was using Ed 5 where I first saw that comment... -- Dave