What does an operating system look like without a shell?

A shell like the bash or command.com (up to Windows ME) or CMD.EXE (in later versions) provides an interface that (among other things) accepts commands from the user. What does an operating system look like before a shell is run? How were systems used before the first shell was developed (e.g. UNIX in the early 1970s)? If a computer cannot even accept commands (there is no command line), how can a user interact with it? What is this most basic interface? Can I run this interface in a terminal emulator or is there no way going behind a shell?

Solution 1:

What does an operating system look like before a shell is run?

Depends on the OS and how you configure it. Linux can be configured to write boot text to a console device, whether a text mode console, framebuffer console or a serial port. It can also be configured to be perfectly silent. Some OS's/systems may write diagnostic information to a non-volatile memory that can be accessed by putting the system in developer, debug, or diagnostic mode. Many operating systems support outputting boot and diagnostic information to some form of UART, which may somehow be available on the unit even if hidden from the user (google "Add serial port to DD-WRT" for examples of where manufacturers hide serial ports and how you can get to them).

An OS doesn't have to have an external display at all - it's just another device to the OS.

How were systems used before the first shell was developed (e.g. UNIX in the early 1970s)?

Essentially (and leaving out a lot but this should get you the idea) - You loaded your program, either by flipping switches on a panel or using a paper-tape reader (these devices would write to memory directly without CPU intervention) and then start the CPU with another switch. The CPU would run this program, generate its output, and stop. This is batch processing as opposed to interactive processing. If you wanted to run a different program you had to do this over.

If a computer cannot even accept commands (there is no command line), how can a user interact with it?

I am no expert in this area but old, old computers like the Altair, IMSAI, and PDP-8 and such had front panel switches that directly controlled the CPU and could directly read and write memory without CPU intervention.

What is this most basic interface?

I believe most if not all modern CPUs have a "JTAG port" which allows the same type of direct operations. Keep in mind that for a long time most computers have been expected to have ROM or firmware that takes control of the system when it is turned on before it hands it off to an OS. Here, pre-boot utilities can exist, or a minimal mechanism for loading such utilities exists. Some bootloaders such as U-Boot can be accessed via the serial port. Bootloaders don't run "behind" the OS, they load the OS, hand control to it, and then they are no longer running.

Can I run this interface in a terminal emulator or is there no way going behind a shell?

No, you need a JTAG interface. That's diving into the realm of electronics and I admit I don't know very much about it, except that my GuruPlug comes with one and I can directly program the flash chip on the GuruPlug's board with it - meaning if something kills the bootloader on the GuruPlug, I have a "CPU independent" way of flashing it back.

Solution 2:

An operating system doesn't have to provide a shell as the term is commonly used today (meaning an application which will accept commands interactively from the user), but such an operating system won't really "look like" anything at all to the user. As Oliver Salzburg mentions, it would probably just show a blank screen (if it has display output support at all), though there's no reason it'd have to. Take for example the Linux kernel's diagnostic output during the boot and kernel initialization process.

The shell, whether a graphical shell, command line interpreter or something else, uses the facilities provided by the operating system to do things like read commands, launch processes, do I/O redirection and so on.

However, there's no reason why the application that uses those facilities has to be a shell.

In the old days, operating systems were simply a collection of those "useful routines" that each application otherwise would have to rewrite from scratch, and computers were essentially batch processing devices. Things like file, disk and printer I/O were probably among the first to be collected into what is now known as an operating system, followed by process scheduling (it's worth noting that the early-1960s Apollo Guidance Computer was a multitasking computer). Applications could then make calls to the OS instead of using their own routines to do such things, which reduced programming complexity and probably helped reduce code size or execution time (because those system facilities could be heavily optimized and debugged once after which everyone would benefit). As computers became more and more common, operating systems added features which were largely user-centered, such as a way for the user to interact with the computer and give commands in an interactive fashion; graphical shells are simply an extension of that line of reasoning.

Also, not that long ago (think up to the late 1980s), it was still fairly common to write applications to run on the bare personal computer hardware, without the assistance of any ordinary operating system. This was particularly useful for games, as it avoided the memory and processing overhead of the operating system proper, but I'm sure there were other examples as well. In those cases, to some extent, the application was its own operating system and by consequence, the user interface provided by that application was the shell.

Solution 3:

Early computers didn't have an OS in the sense we use the word today. They exposed functions implemented in hardware directly to any program running on it. There was only ever one program running on them at the same time. The program itself had to control all tasks, nothing was done 'in the background' by an OS.

But still there was an entry point for the user to start a program. If you stretch the word, you could call this a "shell". But basically, it was just the hardware waiting for the user to input the first bit of the program to be run. Be it in the form of pressed buttons, flicked switches, connected wires on a switchboard, punchcards, punched film or magnetic tape. Maybe they could even choose from several program options loaded earlier. But even selecting from a list displayed as glowing lights by pressing a button next to it can already be considered a 'shell'.

So if your definition of 'shell' is 'an interface that accepts commands from a user', then there was no time before it, at least for devices that you would even vaguely call a computer.

You might want to check out the pretty good wikipedia page about the history of computing, although it doesn't focus much on the input/output perspective.