On Tuesday 23 Sep 2003 4:36 pm, you wrote: > Ian Bell wrote: > > This still confuses me after more than 20 years in this field. I think > > of it this way. In an event driven system, the event being processed is > > the foreground routine. Whatever runs when there are no foreground > > routines to run is the background. This is of course just my personal > > view which may be totaly wrong. > > No, you're using these terms completely correctly. I sure am pleased to > meet you! I thought I was the only one left. :-) Looks like we are both among friends then ;-) > > I learned about background/foreground when working with the IBM mainframe > operating systems for the System/360 and System/370 in the late 1970s. > These were batch-processing systems that divided the available resources > (mainly memory) into "partitions", usually 3-4 foreground partitions that > had the highest priority levels and a background partition that had the > lowest priority. You'd put I/O-bound jobs in the high priority partitions > and compute-bound tasks in the background partition. By extension, since > interrupt service routines have the highest priority by definition, they > are the "most foreground" code. I learnt about it designing ATE systems in the 70's for aerospace applications. > > Things got really confused when the IBM PC and toy (single-task) operating > systems like MSDOS became popular. User code was always operating in > non-interrupt mode (background), but this was in the "foreground" in terms > of the user interface. People starting writing TSR utilities that were > hooked into one interrupt or another (usually the timer tick) to do tasks > that were in the "background" in terms of the user interaction. As a > result, people starting to think of interrupt code in general as being > "background" code, and therefore the non-interrupt code must be the > "foreground" code. Ah, so that's where it came from. Ian -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu