Who'se driving this thing?
June 14, 2011 6:55 PM Subscribe
What was the first computer operating system to use device drivers as we would recognize them today? Bonus question: when was that specific term first used?
I'm pretty sure you had to load some kind of driver-esque thing into the Commodore 64 to use some printers or plotters which didn't just print plaintext. It probably wasn't anything like a driver as we know it today. It may have worked where you spun out a print task into memory (maybe even onto floppy disk) and then the printer software loaded and interpreted the print task for the printer.
We're going back to my teenage years here, and well before I had any knowledge of this kind of computer architecture. And I could be misremembering the entire thing anyway.
posted by hippybear at 7:30 PM on June 14, 2011
We're going back to my teenage years here, and well before I had any knowledge of this kind of computer architecture. And I could be misremembering the entire thing anyway.
posted by hippybear at 7:30 PM on June 14, 2011
There haven't always been device drivers. There was a time when the OS didn't provide much - if you wanted your program to write to a plotter, you wrote code that interfaced directly with the hardware. if someone else wanted to do something similar, they borrowed your code or made their own, but the system didn't define a higher level interface to ease the process. I don't really know when the first system to formally provide these sorts of things, was - I've never *used* a system that didn't provide device drivers. I suspect you'd have to go way back to vertically integrated systems, pre-70s.
posted by RustyBrooks at 7:38 PM on June 14, 2011 [1 favorite]
posted by RustyBrooks at 7:38 PM on June 14, 2011 [1 favorite]
Response by poster: To clarify, I guess by "drivers as we would recognize them today" I mean a set of subroutines usable by multiple applications that abstracts over hardware. Ideally it would abstract in such a way that multiple pieces of hardware could be accessed by the same software by loading different drivers (likely at boot time).
Based on my own research before posting this question I am thinking it was around or before IBM's OS/360 (circa 1965), but was am having trouble finding any concrete info to help resolve the question, thus this askme.
posted by idiopath at 7:59 PM on June 14, 2011
Based on my own research before posting this question I am thinking it was around or before IBM's OS/360 (circa 1965), but was am having trouble finding any concrete info to help resolve the question, thus this askme.
posted by idiopath at 7:59 PM on June 14, 2011
I would define a device driver as follows: 1) there is a clear distinction between user space and kernel space and 2) device drivers are code that is loaded from user space into kernel space in order to communicate with devices.
This definition intentionally excludes OSes like Windows 95 and DOS, in which every program could access the hardware directly.
I would GUESS that the answer is VMS, which was the first commercial OS to really have the modern distinction between user space and kernel space. Windows NT probably had them before Linux -- back when I started using Linux (1.2), it didn't have kernel modules (or they weren't widely used, not sure).
AT&T Unix V7 didn't, last time I played around with it in an emulator.
If you expand to "any shared routines that access hardware..." you're down to "every OS," since the very first OSes were designed to provide common access routines for tape drives.
posted by miyabo at 8:04 PM on June 14, 2011 [1 favorite]
This definition intentionally excludes OSes like Windows 95 and DOS, in which every program could access the hardware directly.
I would GUESS that the answer is VMS, which was the first commercial OS to really have the modern distinction between user space and kernel space. Windows NT probably had them before Linux -- back when I started using Linux (1.2), it didn't have kernel modules (or they weren't widely used, not sure).
AT&T Unix V7 didn't, last time I played around with it in an emulator.
If you expand to "any shared routines that access hardware..." you're down to "every OS," since the very first OSes were designed to provide common access routines for tape drives.
posted by miyabo at 8:04 PM on June 14, 2011 [1 favorite]
Response by poster: Thanks miyabo, that is very helpful. Regarding your suggested definition, what about Minix or plan9, where drivers stay in userspace for security and robustness reasons?
posted by idiopath at 8:14 PM on June 14, 2011
posted by idiopath at 8:14 PM on June 14, 2011
The Mythical Man Month has some pretty detailed descriptions of OS/360. I would start there to see if that doesn't help firm up the definition you are looking for.
posted by roboton666 at 8:30 PM on June 14, 2011
posted by roboton666 at 8:30 PM on June 14, 2011
Requiring run-time-loading for something to be a device driver seems quite weird to me. In earlier days, it was much more common for all drivers to be statically linked into the kernel. Some (closed-source) UNIX systems shipped as a collection of .o files— you would link together the set that corresponded to the hardware you had. (You were assumed to be familiar enough with your hardware to know what drivers you needed.) Even in kernels with many run-time-loaded drivers, many others are statically linked in (for example, the ones which allow the kernel to talk to the disk containing the others).
For what it's worth, Lions' Commentary on UNIX 6th ed. uses the term device driver in the modern (to me) sense in multiple places, and doesn't feel the need to explain the term or anything; it was obviously a well understood phrase by 1977.
posted by hattifattener at 9:33 PM on June 14, 2011 [2 favorites]
For what it's worth, Lions' Commentary on UNIX 6th ed. uses the term device driver in the modern (to me) sense in multiple places, and doesn't feel the need to explain the term or anything; it was obviously a well understood phrase by 1977.
posted by hattifattener at 9:33 PM on June 14, 2011 [2 favorites]
roboton666: good idea. It looks like OS/360 called them access methods. This page says
posted by hattifattener at 9:40 PM on June 14, 2011
Prior to OS/360, even the most dedicated programmers found I/O programming to be a painful process repetitive, inconsistent and error-prone. OS/360 supplied data and telecommunications access methods that simplified the task.which sounds a lot like the access methods were a very early example of providing a programmer-friendly abstraction to hardware. That puts it at 1964.
posted by hattifattener at 9:40 PM on June 14, 2011
The 6809 operating system OS9 had something like what you're talking about. OS9 was amazingly modern, considering when it was written and what kind of hardware it was running on. The 6809 architecture made it pretty straightforward to write position-independent code, and all the standard shell commands, plus device drivers, were written as PIC.
I had a 6809-based system (Radio Shack Color Computer) back in the late 1970's and I ran OS9 on it. With the help of a friend, I built a custom HD interface, and wrote a device driver for it. It wasn't necessary to recompile the kernel in order to use it. (In fact, we didn't have source for the kernel.)
I also wrote a device driver to allow OS9 to use a second RS-232 interface, which was available from RS but wasn't supported by OS9.
posted by Chocolate Pickle at 10:15 PM on June 14, 2011
I had a 6809-based system (Radio Shack Color Computer) back in the late 1970's and I ran OS9 on it. With the help of a friend, I built a custom HD interface, and wrote a device driver for it. It wasn't necessary to recompile the kernel in order to use it. (In fact, we didn't have source for the kernel.)
I also wrote a device driver to allow OS9 to use a second RS-232 interface, which was available from RS but wasn't supported by OS9.
posted by Chocolate Pickle at 10:15 PM on June 14, 2011
I don't know anything about this except what I google'd up but...
The Atlas had paging, interrupts, and what looks to be an early form of device drivers.
Similarly, information intended for output is placed in a common output page, subdivided for the various output devices, and is taken from there by the interrupt routines as required. The interrupt routines for teleprinters and tape punches do the necessary conversion from the internal character code used by the device. As soon as the information for a particular device is exhausted, an S.E.R. is activated to copy fresh information into the common output page. Again, the page is subdivided roughly in proportion to the square roots of the information rates.
The thing was built with transistors, core, and drum memory. The first Atlas was delivered in 1962.
posted by rdr at 10:21 PM on June 14, 2011 [1 favorite]
The Atlas had paging, interrupts, and what looks to be an early form of device drivers.
Similarly, information intended for output is placed in a common output page, subdivided for the various output devices, and is taken from there by the interrupt routines as required. The interrupt routines for teleprinters and tape punches do the necessary conversion from the internal character code used by the device. As soon as the information for a particular device is exhausted, an S.E.R. is activated to copy fresh information into the common output page. Again, the page is subdivided roughly in proportion to the square roots of the information rates.
The thing was built with transistors, core, and drum memory. The first Atlas was delivered in 1962.
posted by rdr at 10:21 PM on June 14, 2011 [1 favorite]
I don't know but the chronology seems obvious.
Device drivers are a form of abstraction in that they package up all aspects of accessing and controlling devices so that programmers can take those matters for granted and get on with their day job. If one already existed you'd borrow it.
Drivers separate from user program are a re-use phenomena that would have sprung from multi-user computers and the recognition that hard jobs were worth doing well - once - and then made available to those who required it. These would necessarily have migrated into operating systems as these emerged.
The notion of 'after market' device drivers would have sprung from retail personal computers where the computer vendor could not predict nor even know what hardware the user would be employing.
Alongside this, standard interfaces would have provided the ground rules for creating vendor independent drivers.
My instinct is to look at the early days of Apple or Digital Equipment (oh! the PDP-11, the finest machine ever).
posted by epo at 3:59 AM on June 15, 2011
Device drivers are a form of abstraction in that they package up all aspects of accessing and controlling devices so that programmers can take those matters for granted and get on with their day job. If one already existed you'd borrow it.
Drivers separate from user program are a re-use phenomena that would have sprung from multi-user computers and the recognition that hard jobs were worth doing well - once - and then made available to those who required it. These would necessarily have migrated into operating systems as these emerged.
The notion of 'after market' device drivers would have sprung from retail personal computers where the computer vendor could not predict nor even know what hardware the user would be employing.
Alongside this, standard interfaces would have provided the ground rules for creating vendor independent drivers.
My instinct is to look at the early days of Apple or Digital Equipment (oh! the PDP-11, the finest machine ever).
posted by epo at 3:59 AM on June 15, 2011
Best answer: Boot-time loading is not something I'd call a requirement to be a "device driver", as a previous poster pointed out.
The GM-NAA operating system had standard, modular operating system routines to access devices in 1956. I'd call those device drivers at some level; might not fit your definition, as GM-NAA was a batch OS, not an interactive one. CTSS could fall into this category as well.
IBMs ACP/TPF system had something I'd sorta call device drivers, but that's probably something that could be argued. That would be late 60s. But I'd agree that OS/360 would be a good place to definitively call them device drivers in a modern sense, though as mentioned, IBM didn't call them that. Of course, TOPS-10 on the PDP-6 came out about the same time, and had device drivers as well. I don't recall which one shipped first.
RT-11 on the PDP-11 certainly had device drivers and called them that starting in, I think, 1973. Initially, the device drivers were added at system configuration time, but later versions allowed for run-time loading.
posted by kjs3 at 10:57 AM on June 15, 2011
The GM-NAA operating system had standard, modular operating system routines to access devices in 1956. I'd call those device drivers at some level; might not fit your definition, as GM-NAA was a batch OS, not an interactive one. CTSS could fall into this category as well.
IBMs ACP/TPF system had something I'd sorta call device drivers, but that's probably something that could be argued. That would be late 60s. But I'd agree that OS/360 would be a good place to definitively call them device drivers in a modern sense, though as mentioned, IBM didn't call them that. Of course, TOPS-10 on the PDP-6 came out about the same time, and had device drivers as well. I don't recall which one shipped first.
RT-11 on the PDP-11 certainly had device drivers and called them that starting in, I think, 1973. Initially, the device drivers were added at system configuration time, but later versions allowed for run-time loading.
posted by kjs3 at 10:57 AM on June 15, 2011
Response by poster: Thanks all for helping satisfy my curiosity. Many good answers here.
posted by idiopath at 12:44 PM on July 15, 2011
posted by idiopath at 12:44 PM on July 15, 2011
This thread is closed to new comments.
Even fairly early computers were configurable. So, you'd order from IBM (or whoever) with a set of options and equipment, and they'd come install it all, and give you a copy of the operating system source code. You'd compile the kernel with the appropriate modules enabled, and away you'd go. (Roughly.)
Many modern unix and mainframe operating systems can still be compiled in this way, with all the device driver modules compiled directly into the kernel. Even OSes where the drivers aren't compiled in still link them in at boot time (Windows). And some OSes allow for hot-loaded drivers for some stuff (USB devices), but not others (graphics cards).
So, I don't know when the term "driver" became popular in software, but I reckon we've had device drivers in a recognizable-by-programmers form for as long as there have been operating systems and optional peripherals/hardware for computers. And a "driver circuit" is an old concept, and hackers shamelessly steal hardware terms, so it wouldn't surprise me if "driver" as a software term is nearly as old.
Now, if you mean specifically drivers that can be loaded at any time during the operation of the computer (not just boot time), then the credit may actually go to linux if a little research is to be believed. I'm not certain I believe them, but there are claims that linux pioneered the idea of the runtime loadable module. And it is certainly plausible, although one of the other PC OSes may take the real prize: BeOS or NeXTStep or something.
posted by Netzapper at 7:25 PM on June 14, 2011 [4 favorites]