In a command-line environment of a contemporary Unix-like system, it is possible to "type ahead", that is, for example, to start a process which runs for a while and does not require any console input, and to type the next shell command while the process is running, including Enter, so that the shell will execute that next command as soon as the currently running process finishes, because the OS would buffer the input even though there was no application waiting for that input while it was keyed in.

That feature was not universal; for example, MS DOS did not have it, as far as I remember.

Which OS featured the type-ahead capability the earliest?

In more detail, this is the desired scenario, in "pseudocode":

[some kind of prompt from the OS or an application] RUN PROGRAM 1 [Enter]
[while the calculation is running, unprompted, may or may not be echoed] RUN PROGRAM 2 [Enter]
[the user goes away for quite a while; after returning, they may see...]
[output from PROGRAM 1]
[optionally, a prompt and (re-)echoed "RUN PROGRAM 2"]
[output from PROGRAM 2]
[a prompt]
  • 1
    Before voting to close for the reason "Needs details or clarity", please comment what exactly is unclear.
    – Leo B.
    Mar 3, 2022 at 22:27
  • Sadly for @Raffzahn his beloved early IBM 360s were not among them! (AFAIR)
    – davidbak
    Mar 3, 2022 at 22:53
  • 2
    @davidbak Of course they were among. Block mode terminals do collect the whole screen and send it only when ordered. But even before that, printing terminals collected a line until send.
    – Raffzahn
    Mar 3, 2022 at 23:08
  • 4
    I don't know the answer, but when I started using computers in 1974, "typeahead" was so ubiquitous that I didn't even know it was a feature, until later on when I encountered weenie little microcomputers that lacked it. Mar 3, 2022 at 23:14
  • 1
    Regarding some comments made I vote for closure as teh scope seems to be unclear. On one side it asks for type ahead, which is a low level hardware function (hardware or driver), but at the same time it asks for commands, shells and processes, which is a high level function specific to certain OS or OS types.
    – Raffzahn
    Mar 4, 2022 at 0:08

7 Answers 7


Multics, the predecessor to Unix, had type-ahead. It was initially released in 1969. The most common terminal in the beginning was the IBM 2741, but the standard 2741 would lock the keyboard after a carriage return. 2741s for Multics had an extra switch to disable this feature, allowing type-ahead.

Multics also supported model 37 Teletypes, which needed no special modification, as the keyboard and printer were essentially independent mechanisms with no logical connection within the device.


MS-DOS did not have a type-ahead feature, because that function was provided by the BIOS. A typical PC BIOS had a 15 or 16 character typeahead buffer, where keystrokes would be queued until something (perhaps the next DOS prompt) asked to read more. This buffer was a limited size and would typically cause a "beep" if you typed another key after it was full.

Earlier, there were add-on devices for the Apple II that added this functionality. I remember using one called an "Enhancer II" which replaced a lot of keyboard functionality, offering features like lower case, keyboard macros, and a typeahead buffer.

  • 4
    That's a comment, not an answer.
    – Leo B.
    Mar 3, 2022 at 22:12
  • 12
    @LeoB. I'd actually argue that this is a very important answer because it highlights what you appear to have missed - the fact that it's not necessarily an OS feature in the first place. If it can be implemented at an even lower level, then no operating system would need to be the first to implement it in itself. Surely, it does not answer your question, but perhaps the question it answers is much more important and arguably the more correct one to ask. Of course, with async event handling, the OS creates an event queue of its own, but historically, it clearly wasn't a necessity.
    – natiiix
    Mar 4, 2022 at 17:49
  • 1
    @natiiix "perhaps the question it answers is much more important and arguably the more correct one to ask" For that, one is perfectly free to pose and self-answer a separate question.
    – Leo B.
    Mar 4, 2022 at 21:35
  • It feels like we're talking about two different things. A small amount of input buffering in hardware is not "typeahead". E.g., a DH11 terminal multiplexer had a 64-word silo to store incoming characters from the 16 terminal lines. This usefully increases the time the CPU has to react to input interrupts. Mar 5, 2022 at 15:27
  • 4
    @LeoB. Sure, but also no. People often Google the wrong questions, and if none of the answers correct their underlying assumption and try to answer the literal question, then they may never learn their mistake. Frankly, I rarely look through comments and linked questions unless I'm really desperate. Often times, the best answer is one that, arguably, doesn't even answer the original question, but rather proposes an alternative point of view, which is much more helpful than a technically correct answer. I respect your point of view, but I don't believe it's necessary to be so pedantic on SO/SE.
    – natiiix
    Mar 5, 2022 at 22:05

Type-ahead was originally not an operating-system function, but rather a function of a terminal controller that was separate from the CPU and might have either a dedicated buffering subsystem for each terminal port, or a dedicated microcomputer [which may be discrete-logic based or microprocessor-based] to handle multiple terminals. The main CPU could only have one task at a time loaded into memory, and it made more economic sense to buffer typed characters in external hardware than to add enough memory to the main CPU to handle incoming data itself.

As for personal computers, I don't know what the TRS-80 or CP/M based computers did.

I think the Atari personal computers had a POKEY chip which scanned the keyboard and would be asked 50 or 60 times/second by the default interrupt handler to check whether it had a key, and then kept some kind of buffer, but I don't know the details.

The Apple II had a keyboard circuit that would autonomously scan the keyboard and set a latch when a key was available. When it set the latch, it would also capture the ASCII value of the key, and the latch would remain set until software cleared it. On older machines in the family, keyboard repeat was handled by hardware which would periodically re-set this latch while a "repeat" button was held. The Apple //e and later machines used a keyboard controller chip which included repeat functionality when keys were held down.

The Commodore 64 used a 50/60Hz timer tick routine to strobe all eight rows of the keyboard matrix, check what keys were held down, and if appropriate store whatever key was held into a 10-character buffer.

The IBM PC had a dedicated micrcontroller inside the keyboard which would autonomously poll it and record key-press and key-release events. I think a typical keyboard had a buffer that could hold 32 such events. Whenever an event occurred, the BIOS would receive an interrupt, retrieve a press/release event, check whether the keys were modifier keys, and either set/clear bits in a certain pair of bytes if they were, or use the aforementioned byte along with the scan code to generate a character code, which would then be put into a 15-character buffer. If this buffer was full, the system would beep briefly (suspending program execution while it did so).

On most or all of the aforementioned personal computers (I'm not sure about the TRS-80 or CP/M) there were separate system routines to for "read one character" and "read line of input", with the latter routine generally offering some forms of editing capability beyond just backspace. On the PC, many popular utilities could replace the default line editor (which was rather crude) with a better one. A nice benefit of having a dedicated line-input function is that code which called it could indicate how many characters were desired, and provide feedback if that number was exceeded. This was not possible on Unix-based or other systems that would accept lines of input before knowing what needed to be done with them.

  • An answer to my question would pre-date any microcomputers. Whether it was an OS with buffers in memory, or a system with a terminal controller providing the typeahead functionality, it would be something from the 60s.
    – Leo B.
    Mar 4, 2022 at 17:05
  • @LeoB.: The big-iron systems generally didn't include type-ahead capability in the OS. Since you'd asked about the PC, I included some historical perspective up through that era.
    – supercat
    Mar 4, 2022 at 17:08
  • In a comment to the question, SolomonSlow says "... in 1974, "typeahead" was so ubiquitous that I didn't even know it was a feature".
    – Leo B.
    Mar 4, 2022 at 17:29
  • @LeoB.: I wonder how much typeahead was actually common, given that in many cases a user of a system connected to a terminal wouldn't be able to tell when the system actually received their input. It was certainly not present on the Apple II, and I suspect that while some CP/M systems supported it, there were probably just as many that did not.
    – supercat
    Mar 4, 2022 at 17:47

First? Don't know, but from personal knowledge TOPS-10 had it, around 1974, in the 5-series monitor. Probably before that, but I wasn't using it.

A 1989 course on TOPS-10 internals, while way too recent to qualify as evidence for early implementation, has this to say about mechanism:

Characters from a terminal keyboard are stored in an input chunk stream until they are requested as input by the program or as a command by the monitor.

i.e., it describes typeahead. I recall the same tty chunks structure from the mid-1970s.

RSX-11D on PDP-11 likewise had typeahead at around the same time, as did RSTS/E and possibly RSTS-11.

I suspect this is an 'obvious' feature for interactive timesharing systems. The job/process/task may not be in core, you've got to accumulate characters somewhere, so why not accumulate them even in the absence of an outstanding read? (If there is even an explicit 'read' from the command interpreter; sometimes there's just a cosy arrangement with the terminal driver).

It makes for smoother user interaction on a loaded system if you don't have to wait for the next prompt before touching the keyboard.

I can scour the manuals later to push the date back some more, but certainly microprocessor-based systems did not invent this.

  • Sure they did not. I was wondering which system had it before Unix.
    – Leo B.
    Mar 3, 2022 at 23:49
  • 3
    AFAIK "The Monitor" on the PDP-6 had typeahead in 1965. The monitor is what later became TOPS-10. Mar 4, 2022 at 13:06
  • 1
    I've found it surprisingly difficult to find typeahead mentioned in DEC doc. Maybe it's because as someone else said, it wasn't regarded as a "feature". By contrast, I was surprised when RSX-11M didn't work like that: in general, when you typed an MCR command line, it was executed "now", regardless of whether the last task you started was still running. Mar 4, 2022 at 13:07
  • @WalterMitty - I thought it likely, but couldn't find any statement in the doc, and balked at trying to figure it out from SCNSER. Mar 4, 2022 at 13:08
  • Very early DEC machines, like the PDP-1, came with no operating system. For that reason, discussion of type ahead would be almost meaningless. And if the hardware supported multiprogramming, it's hard to imagine how it could have worked without either typeahead or locking keyboards. I have a PDP-6 manual somewhere. If I can find it, I'll see whether it says anything relevant to the current topic. Mar 4, 2022 at 18:27

On the DEC minicomputers, Typeahead was indeed an OS function, as it could be turned off in certain circumstances, at least by the time of VMS. I'm pretty sure that was the case on the major PDP timesharing -- RSX and RSTS.

DEC minicomputers normally did not use block mode terminals. All terminal I/O was character at a time (a gross oversimplification, but okay for this discussion).

Some DEC OS's (the only ones I "grew up" on) did the immediate echo, while others, e.g., VMS, buffered the echo until there was a read request, as mentioned above.

  • If DEC definitely had that feature in an OS pre-dating Unix, that could be it.
    – Leo B.
    Mar 4, 2022 at 21:32
  • 1
    There was some PDP-11 terminal driver which allowed you to choose immediate echo versus echo at the time of read. I'm thinking it was probably on IAS. Mar 5, 2022 at 15:37

While not a direct answer, the first systems with type ahead capability would likely have been ones which used a fairly smart terminal. If I remember correctly, the VT-100 (etc) had a type ahead mode which would internally buffer a line of text until the system was ready for it. It's been decades, so I don't really remember this feature; I just sort of remember that it was there, but I never used it.

Sorry for the non "dumb-terminal" answer, but a lot of terminals from the day were not completely dumb.

  • VT-100 manuals may be available online.
    – Leo B.
    Mar 4, 2022 at 17:08
  • 1
    No, the VT100 is way late with respect to this question. DEC systems exhibited typeahead years before the VT100, including when using the supremely unintelligent but lovable ASR33 teletype. For absolute certainty, typeahead was stored in kernel buffers in DEC timesharing operating systems. Mar 5, 2022 at 3:19
  • The VT100 certainly had a small (64 char) output buffer. It wouldn't surprise me if it had a (smaller) input buffer, since the host could XOFF the terminal, and it might be advantageous to buffer a few keystrokes. But that's not really in the spirit of what I perceive the question to be. Mar 5, 2022 at 3:29

That feature was not universal; for example, MS DOS did not have it, as far as I remember.

Well, it did not, as it used the type ahead buffer the BIOS provided. By default that would be 16 bytes. It was quite useful to work at acceptable speed with diskette drives. Already these 16 bytes were quite useful and allowed to enter at least one command ahead, while the last was still processed. More so when extended by a TSR to 60 or 100 bytes. They showed up quite early. I could have never used a 4.77 MHz PC without.

The PC-BIOS was not the first to do so. Similar was offered by many BIOS for CPM, or other computers.

Furthermore, MS-DOS offered a read line function (Int 21h/0Ah, Buffered Input) to improve responsiveness for line input. This is not only handy for tool development, but guarantees shortest possible response between hitting a key, displaying it and executing edit commands (BS at least), independent of existence of buffers or buffer depth.

Just keep in mind how slow early computers were. If each character typed had to be handled all the way up to application level, usability for office application might not always be possible.

Which OS featured the type-ahead capability the earliest?

It's not really an OS feature, but usually located at the hard/software boundary. Many computers offered a type ahead. From the Apple II's 1 character deep buffer all the way to keyboard controllers like Intel's 8279 offering an 8 character buffer in hardware.

Likewise, back in the age of mainframe terminals, the whole character based handling was offloaded not only to I/O hardware but to external terminals/terminal controllers. A Block mode terminal, like the ubiquitous 3270 allowed complete local editing of not only a line but many thereof complete without OS (or application) intervention.

Similar for printing terminals like the 2740 family. Here a line is collected by I/O (not CPU) until finished by pressing Return or ATentioN. Only then the CPU is alerted and the line handed over for processing to whatever program (OS or an application using direct I/O) takes it from there.

After all, mainframes were block orientated by nature:

  • Punch Card In
  • Print Line Out

Block orientation is the very foundation of the high thruput these machines provided.

Long story short: Buffered keyboard input was there before unbuffered.

(Excluding experimental systems that is)

  • Let me repeat the pertinent part of the question: ...including "Enter", so that the shell will execute that next command as soon as the currently running process finishes...
    – Leo B.
    Mar 3, 2022 at 23:48
  • 1
    I think the question is asking about a feature in the terminal driver where it would collect input characters before there was a read for them. Depending on implementation, the echo either happened immediately (good for user feedback) or not until read (good for making sure the printed record was correct). Mar 3, 2022 at 23:49
  • @LeoB. Well, that is exactly how it works using a 2741 (and described above). A line is collected until return is pressed, at which time the CPU is alerted about a new line being available - ready to be processed whenever the program in charge likes to do so.
    – Raffzahn
    Mar 4, 2022 at 0:00
  • @LeoB. Or is that question on purpose restricted to use of a 'shell' and 'processes' as Unix does? That would make it a self serving question with only one valid answer: Unix. Also, it would need to be reworded, as type ahead is something else than buffering a 'command' ahead.
    – Raffzahn
    Mar 4, 2022 at 0:02
  • 1
    I don’t agree with the Buffered Input function (the utility used for input by the DOS command prompt itself, as well as simpler programs such as EDLIN and DEBUG) as “improv[ing] responsiveness for line input” [by processing keystrokes before handing them to the application]. It was certainly a very convenient (free) way to prompt for input for console-style programs, but it was unusable for full screen UI (because of how it reacted to ESC, etc.), and it didn’t run any faster than what any application could do on its own. Can you clarify what you meant? Mar 4, 2022 at 4:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .