It's interesting, I was thinking about this the other day too. I remember talking about the 'main program' in Fortran when I was learning. I never thought about it when I saw it in C, other than, ok that's how you pass command line args, which I thought was really clean. I remember TOPS and TSS you had to go rummaging around to get to them. As for your BCPL question, START() was way I learned it. I think I first saw it on the 360s or maybe the 1108; but really never did much it until I saw the first Altos. Clem On Fri, May 22, 2020 at 2:53 PM Lawrence Stewart <stewart(a)serissa.com> wrote:

On Fri, May 22, 2020 at 11:54 AM Lawrence Stewart <stewart(a)serissa.com> wrote: In general, Multics does not have a concept of "main"; the entry point of a program is the name of the program. Looking at the Multics runoff sources (written in BCPL) we see in the segment runoff_driver.bcpl: external $( RunoffCommand = "runoff" ... let RunoffCommand () be main $( MONITOR := Open (StreamName + Write, "error_output") // Errors, etc. written here. ... BCPL replaces the name RunoffCommand with runoff during compilation; the compiled segment runoff_driver will have an entry point "runoff". Entering the command "runoff" will search segments in the search path for that entry point. Since segments can have multiple entry points, the idea of "main" (or "start" or "start_") as the defining entry point is not meaningful in Multics. The Multics C compiler (based on PCC) does have a concept of main; the C linker aliases that to the segment name, making the entry point name the same as the segment name. Thus compiling and linking foo.c generates a segment foo with an entry point foo, which points to main. (Actually, it aliases it to the C runtime library initialization which calls main.) -- Charles -- Charles

This is straying way off topic, but I thought it would be interesting to look at a couple of older sources about it, say, from the late 1940s when there were computers with programs. A search on Google Books in the date range 1800-1950 gives a lot of hits (at least 10 screens worth). Since it’s Google, your results may vary, but here are the first few I got: - US Congress hearings on National Health Program, 1946: "Any discussion on either the main program or the amendment to…” Fair enough. Got the phrase, it’s in the range. Just not relevant to the current investigation. - C Programming: Test Your Skills by Ashok Kamthane, dated by Google Books to 1900 - Information Circular, dated 1925, with the excerpt starting “It consists of a main program, two subroutine subprograms, A macro-flow chart of the program is shown on figure A-1”. Which seems odd, because that pretty clearly isn’t really from 1925. So I clicked through the document, which turns out to be Information Circular 1601: Corrosion Resistance of Metals in Hot Brines: A Literature Review” published by the US Bureau of Mines in 1973. It also does not have the excerpt in the document. - Programming Techniques Through C: A Beginners Companion by M. G. Venkateshmurthy, dated 1900. - Technical Bulletin, Issues 206-216, dated 1922 with the excerpt "The main program (MAIN) will be discussed first and then each of the subroutines called by the main program. Sometimes the subroutines called by the main program call other subroutines.”. Clicking through to it gives the response “No results in this book for ‘main program’”. This turns out to be incorrect, because somewhere between the Google Books server and my Safari browser the search string was mishandled. Changing it in the search box gives 3 snippets referencing “main program”, and the document is apparently about a FORTRAN program compiled with the CDC6400 FTN version 3 compiler. However, nothing more than the snippets is available and the 1922 date is obviously wrong. Remaining items on the first page are similarly clearly misdated or about non-computer main programs. No one said archival research is easy, but Google Books does present itself as having better data than it delivers. - Win