First Computer Operating System

                   Before making any conclusions about which was the first Operating System (OS), we will have to see what exactly is an OS, in brief very briefly actually.

An OS is a piece of software which acts as a mediator between the bare hardware and application programs. The definition which is supported by most of the programmers is: An OS is collection of programs (or “modules” in nerd-speak), that manages, and controls the resources of a computer or other computing device, and gives user and programs an interface to utilise these resources.

For further definition, and explanation read "Definition of OS" or if you can carry none the less.

                   Just like the computer hardware, the operating system wasn’t created overnight, but unlike the hardware nobody was trying to create an OS intentionally. The very first few operating systems were results of evolution taking place within the world of computing. Few milestones can be mentioned here, in the chronological order:

Programs > Loaders > Monitors > Operating Systems

                   Problematically enough, there was no term coined as “Operating System”, and the early operating systems were nothing but the next step of the ”Monitors” in the evolution. So there is a very thin line between the monitors and OS’s of these days. Which makes even difficult to track down the first OS.

                   Coming to the point: for a very long time now the first operating system was thought to be “GM-NAA I/O”, which stands for “General Motors – North American Aviation I/O” System. (Where again I/O stands for input/output.) This system was created in 1956 for IBM-704 computer system, by Robert Patrick of General Motors Research, and Owen Mock of North American Aviation. ^{[1] [2]}

                   The GM-NAA I/O system was based on a system monitor created by programs of General Motors for its IBM-701. This system monitor was created in 1955. Recently from studying the codes of both, GM-NAA I/O (IBM-704), and the system monitor of IBM -701, it has been debated that the system monitor was mature enough to be called as an operating system.

                   IBM-701, well known by its nick name “Defence Calculator”, was made public circa 1952, but the system monitor in discussion was created in 1955 by GM, and the GM-NAA I/O (1956) system was actually based on the system monitor. ^[3]

There is more!

The quest yields one more name, which is chronologically the first one: “Tape Director Program”. ^[4] It is sometimes also called as director tape program. It was created in 1954 by MIT for UNIVAC 1103. UNIVAC 1103 was a competitor of IBM 701 in the field of “Scientific Computation”. Yet, it is believed by most that the tape director program, even though almost an operating system, was not entirely operating system.

                   The information provided above leaves us with two doubts/questions.

• Which monitor/program was developed/mature enough to be termed as an OS?

• Was there any other fully developed monitor, which actually was an operating system but we don’t know about it?

The secrecy of such particular projects, can also be the reason for our problem here, as most of this events/development took place in the period of World War II, and Cold War. The first completely electronic computer was supposed to be ENIAC, which is purely a misunderstanding. I will soon update an article, which solidly proves that ENIAC wasn’t the first electronic computer.

References:

1: http://www.computerhistory.org/timeline/?year=1956 ("Software and Languages" Section)
2: http://www.softwarepreservation.org/projects/os/gm.html
3: http://ieeexplore.ieee.org/stamp/stamp.jsp?reload=true&tp=&arnumber=4640507&isnumber=4640446 
4: http://www.csail.mit.edu/timeline/timeline.php/timeline.php?query=event&id=3

usernamekiran

Process Management in CP/M

                   By now, we've seen the basics of I/O, and memory management of CP/M, it is time for process management. As CP/M is a single process operating system, the process management is quite limited. Still, even with this limited functionality, there are several issues regarding processes that the operating system must handle. Generally, when a program is being executed, it is called as a process. So, first we will take a brief look at program execution, and then we will move to process management.

Executing an application program:

                   To execute a program, its executable code must be loaded into memory. Usually, this loading is done by CCP (through loader). CCP accomplishes its work by making BDOS calls only. As CCP is loyal friend of BDOS; CCP never calls BIOS, or hardware directly. CCP always calls them them through BDOS. When a set of characters is entered in CCP, first of all, CCP checks if this set of characters is a built-in command or not. If it is command, then it is executed. If it isn't a built-in command then CCP looks for an executable program file on the disk by that name. In both the cases, the executable code of that file/program is loaded into the memory, and the execution of the program begins.

Command Processing Via CCP:
                        In CP/M, CCP is a program, pretty much like any other program. The CCP is better structured than most of the programs, as it only uses OS system calls, and never bypasses the operating system/BDOS. In other operating systems a component similar to CCP, is sometimes called as a shell, command interpreter, or command line interface. In CP/M a user can directly invoke CCP command by typing the command, or by typing the name of an executable file. The CCP is configured to load in high memory location, just below the BDOS. When a program starts executing, and if the memory is insufficient, then CCP exits the memory creating free space for the program. When a program finishes the execution, it exits with returning control to the BDOS. Then the BDOS checks if the CCP is still in the memory, or not. If it is in the memory, then BDOS returns control to CCP. But if CCP is not in the memory(exited from memory, for making memory available for the program, as mentioned previously),  then the CCP is reloaded into the memory, and given control.

Basic “MULTITASKING” In CP/M:
                        Even in the early days of computing, users wanted to do some work in parallel. Most common request was to print data, and edit another file on the computer system at the same time. Because in these days, printers were very slow. It required 30 to 60 minutes to print out few pages. So this time was obviously wasted, while computer did nothing but printing. In these days, most of the users used to start the printing process, and then they used to do something else, like eating reading, or visit a friend to discuss how many balloons would it take to hover a cat? (come on, what are the odds? There must be atleast one user who did this) But if something went wrong, and user returned after a long time, to find that printer needs some attention, and most of the printing hasn’t been done. Well, this is obviously keyboard pounding frustrating! And this used to happen quite sometimes.
                        Gary’s solution was a background printing process. In CP/M, when a user gives command to print a file, then a small program is loaded into the memory. Let us call that program as “print handler”. This print handler is loaded at the highest location in the memory, just underneath the OS. This program initialises itself, and gives control to CCP, allowing another program to be run. This background printing process usually gets control when the CPU is idle, or if the foreground process makes system call, or by setting a timer which causes an interrupt to the foreground process. This background process prints a little bit of a file, a line or two, whenever it gets control.
                        Even though the computer did not do it, this background processing gave appearance of computer doing two things at the same time, something called as multi-tasking. But still, users liked this idea of doing two things at the same time.

Overlays In CP/M

                        This concept of “overlays” is going to be simple with CP/M. But in more advanced operating systems, this is going to be a little trickier. The maximum of memory in CP/m was constrained, by the amount of the memory that processor could address. Initially this was 64 KB (with Intel 8080, 8085, Zilog Z-80), but some processors which were introduced later, allowed more memory to be addressed. But what if a program would not fit in the available memory space? This problem has been an issue, almost since the birth of electro-mechanical computing.
                        A human can solve this kind of problem very easily: If the available space is small, then bring only what is needed at a time. But computers only do the things that they are told to do. So after tell it, a program that manipulates large amount of data, brings only the required data on memory, remaining data is kept on the disk till it is needed. Similar stuff is done with programs, which have large binary codes: only the required code is brought in the memory. These parts “overlay” each-other at the same location in memory, and are called as overlays.
                        Programs with large amount of binary code, have to be divided into different parts. The main part of the program is always memory resident. The programmer (while conceiving the program) has to identify the parts of the program, that should be grouped together in an overlay. While designing this, it is important to avoid one overlay calling a different overlay that would take the place of the first one in memory. Actually, loading of the overlays is done by the programming language’s runtime library, which uses CP/M OS system calls to load an overlay. The programmer has to indicate the compiler that which parts of a program, which functions, and procedures should be in each overlay. Then the compiler produces the loadable overlay code. In following diagram, the program has one main part and three overlays. Only one of the overlay will be in memory at any particular time.