Ian Bell <ian@RUFFRECORDS.WORLDONLINE.CO.UK> 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. :-)

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.

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.

This is, of course, completely backwards. But since DOS hackers now
outnumber professional programmers by several orders of magnitude, it's
the more common usage these days. :-(

-- Dave Tweed

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu