<programming, operating system> (Or "application", "app") A
	complete, self-contained program that performs a specific
	function directly for the user.  This is in contrast to system
	software such as the {operating system} {kernel}, {server}
	processes and libraries which exists to support application
	programs.

	Editors for various kinds of documents, {spreadsheets}, and
	text formatters are common examples of applications.  Network
	applications include clients such as those for {FTP},
	{electronic mail}, {telnet} and {WWW}.

	The term is used fairly loosely, for instance, some might say
	that a client and server together form a distributed
	application, others might argue that editors and compilers
	were not applications but tools for building applications.

	One distinction between an application program and the
	operating system is that applications always run in "user
	mode" (or "non-privileged mode"), while operating systems and
	related utilities may run in "supervisor mode" (or "privileged
	mode").

	The term may also be used to distinguish programs which
	communicate via a {graphical user interface} from those which
	are executed from the {command line}.

	(1994-11-28)

1. A discrepancy between a computed, observed, or measured
	value or condition and the true, specified, or theoretically
	correct value or condition.

	2. <programming> A mental mistake made by a programmer that
	may result in a program {fault}.

	3. (verb) What a program does when it stops as result of a
	programming error.

	(2000-03-28)

1. A new or better version of some {hardware} or {software}.

	Often used in {marketroid}-speak to mean "{bug fix}".

	2. The act of developing or installing a new version.

	(1995-03-14)

<programming> One of a sequence of copies of a program, each
	incorporating new modifications.  Each version is usually
	identified by a number, commonly of the form X.Y where X is
	the major version number and Y is the release number.
	Typically an increment in X (with Y reset to zero) signifies a
	substantial increase in the function of the program or a
	partial or total re-implementation, whereas Y increases each
	time the progam is changed in any way and re-released.

	Version numbers are useful so that the user can know if the
	program has changed ({bugs} have been fixed or new functions
	added) since he obtained his copy and the programmer can tell
	if a bug report relates to the current version.  It is thus
	always important to state the version when reporting bugs.
	Statements about compatibility between different software
	components should always say which versions they apply to.

	See {change management}.

	(1997-12-07)

<programming> An unwanted and unintended property of a program
	or piece of hardware, especially one that causes it to
	malfunction.  Antonym of {feature}.  E.g. "There's a bug in
	the editor: it writes things out backward."  The
	identification and removal of bugs in a program is called
	"{debugging}".

	Admiral {Grace Hopper} (an early computing pioneer better
	known for inventing {COBOL}) liked to tell a story in which a
	technician solved a {glitch} in the {Harvard Mark II machine}
	by pulling an actual insect out from between the contacts of
	one of its relays, and she subsequently promulgated {bug} in
	its hackish sense as a joke about the incident (though, as she
	was careful to admit, she was not there when it happened).
	For many years the logbook associated with the incident and
	the actual bug in question (a moth) sat in a display case at
	the Naval Surface Warfare Center (NSWC).  The entire story,
	with a picture of the logbook and the moth taped into it, is
	recorded in the "Annals of the History of Computing", Vol. 3,
	No. 3 (July 1981), pp. 285--286.

	The text of the log entry (from September 9, 1947), reads
	"1545 Relay #70 Panel F (moth) in relay.  First actual case of
	bug being found".  This wording establishes that the term was
	already in use at the time in its current specific sense - and
	Hopper herself reports that the term "bug" was regularly
	applied to problems in radar electronics during WWII.

	Indeed, the use of "bug" to mean an industrial defect was
	already established in Thomas Edison's time, and a more
	specific and rather modern use can be found in an electrical
	handbook from 1896 ("Hawkin's New Catechism of Electricity",
	Theo. Audel & Co.)  which says: "The term "bug" is used to a
	limited extent to designate any fault or trouble in the
	connections or working of electric apparatus."  It further
	notes that the term is "said to have originated in
	{quadruplex} telegraphy and have been transferred to all
	electric apparatus."

	The latter observation may explain a common folk etymology of
	the term; that it came from telephone company usage, in which
	"bugs in a telephone cable" were blamed for noisy lines.
	Though this derivation seems to be mistaken, it may well be a
	distorted memory of a joke first current among *telegraph*
	operators more than a century ago!

	Actually, use of "bug" in the general sense of a disruptive
	event goes back to Shakespeare!  In the first edition of
	Samuel Johnson's dictionary one meaning of "bug" is "A
	frightful object; a walking spectre"; this is traced to
	"bugbear", a Welsh term for a variety of mythological monster
	which (to complete the circle) has recently been reintroduced
	into the popular lexicon through fantasy {role-playing games}.

	In any case, in jargon the word almost never refers to
	insects.  Here is a plausible conversation that never actually
	happened:

	"There is a bug in this ant farm!"

	"What do you mean?  I don't see any ants in it."

	"That's the bug."

	[There has been a widespread myth that the original bug was
	moved to the Smithsonian, and an earlier version of this entry
	so asserted.  A correspondent who thought to check discovered
	that the bug was not there.  While investigating this in late
	1990, your editor discovered that the NSWC still had the bug,
	but had unsuccessfully tried to get the Smithsonian to accept
	it - and that the present curator of their History of
	American Technology Museum didn't know this and agreed that it
	would make a worthwhile exhibit.  It was moved to the
	Smithsonian in mid-1991, but due to space and money
	constraints has not yet been exhibited.  Thus, the process of
	investigating the original-computer-bug bug fixed it in an
	entirely unexpected way, by making the myth true!  - ESR]

	[{Jargon File}]

	(1999-06-29)

1. See {multithreading}.

	2. See {threaded code}.

	3. {topic thread}.

	[{Jargon File}]

1. <networking> {e-mail address}.

	2. <networking> {Internet address}.

	3. <networking> {MAC address}.

	4. <storage, programming> An unsigned integer used to select
	one fundamental element of storage, usually known as a {word}
	from a computer's {main memory} or other storage device.  The
	{CPU} outputs addresses on its {address bus} which may be
	connected to an {address decoder}, {cache controller}, {memory
	management unit}, and other devices.

	While from a hardware point of view an address is indeed an
	integer most {strongly typed} programming languages disallow
	mixing integers and addresses, and indeed addresses of
	different data types.  This is a fine example for {syntactic
	salt}: the compiler could work without it but makes writing
	bad programs more difficult.

	(1997-07-01)

<character> The space character, {ASCII} 32.

	See {octal forty}.

<electronics> The quantity of {charge} per unit time, measured
	in Amperes (Amps, A).  By historical convention, the sign of
	current is positive for currents flowing from positive to
	negative {potential}, but experience indicates that electrons
	are negatively charged and flow in the opposite direction.

	(1995-10-05)

<operating system> /day'mn/ or /dee'mn/ (From the mythological
	meaning, later rationalised as the acronym "Disk And Execution
	MONitor") A program that is not invoked explicitly, but lies
	dormant waiting for some condition(s) to occur.  The idea is
	that the perpetrator of the condition need not be aware that a
	daemon is lurking (though often a program will commit an
	action only because it knows that it will implicitly invoke a
	daemon).

	For example, under {ITS} writing a file on the {LPT} spooler's
	directory would invoke the spooling daemon, which would then
	print the file.  The advantage is that programs wanting files
	printed need neither compete for access to, nor understand any
	idiosyncrasies of, the {LPT}.  They simply enter their
	implicit requests and let the daemon decide what to do with
	them.  Daemons are usually spawned automatically by the
	system, and may either live forever or be regenerated at
	intervals.

	{Unix} systems run many daemons, chiefly to handle requests
	for services from other {hosts} on a {network}.  Most of these
	are now started as required by a single real daemon, {inetd},
	rather than running continuously.  Examples are {cron} (local
	timed command execution), {rshd} (remote command execution),
	{rlogind} and {telnetd} (remote login), {ftpd}, {nfsd} (file
	transfer), {lpd} (printing).

	Daemon and {demon} are often used interchangeably, but seem to
	have distinct connotations (see {demon}).  The term "daemon"
	was introduced to computing by {CTSS} people (who pronounced
	it /dee'mon/) and used it to refer to what {ITS} called a
	{dragon}.

	[{Jargon File}]

	(1995-05-11)

To produce something according to an {algorithm} or program or
	set of rules, or as a (possibly unintended) {side effect} of
	the execution of an algorithm or program.

	The opposite of {parse}.

	[{Jargon File}]

	(1995-06-15)

<programming> A computer system or process that requests a
	service of another computer system or process (a "{server}")
	using some kind of {protocol} and accepts the server's
	responses.  A client is part of a {client-server} software
	architecture.

	For example, a {workstation} requesting the contents of a file
	from a {file server} is a client of the file server.

	(1997-10-27)

<jargon, architecture> (Via the technical term {virtual
	memory}, probably from the term "virtual image" in optics)
	1. Common alternative to {logical}; often used to refer to the
	artificial objects (like addressable {virtual memory} larger
	than physical memory) created by a computer system to help the
	system control access to shared resources.

	2. Simulated; performing the functions of something that isn't
	really there.  An imaginative child's doll may be a virtual
	playmate.

	Opposite of {real} or physical.

	[{Jargon File}]

	(1994-11-30)

<language> One of the most used {object-oriented} languages, a
	superset of {C} developed primarily by {Bjarne Stroustrup}
	<bs@alice.att.com> at {AT&T} {Bell Laboratories} in 1986.

	In C++ a {class} is a user-defined {type}, syntactically a
	{struct} with {member functions}.  {Constructors} and
	{destructors} are member functions called to create or destroy
	{instances}.  A {friend} is a nonmember function that is
	allowed to access the private portion of a class.  C++ allows
	{implicit type conversion}, {function inlining}, {overloading}
	of operators and function names, and {default function
	arguments}.  It has {streams} for I/O and {references}.

	C++ 2.0 (May 1989) introduced {multiple inheritance},
	{type-safe linkage}, pointers to members, and {abstract
	classes}.

	C++ 2.1 was introduced in ["Annotated C++ Reference Manual",
	B. Stroustrup et al, A-W 1990].

	{MS-DOS
	(ftp://grape.ecs.clarkson.edu/pub/msdos/djgpp/djgpp.zip)},
	{Unix ANSI C++
	(ftp://gnu.org/pub/gnu/g++-1.39.0.tar.Z)} - X3J16
	committee. (They're workin' on it).

	See also {cfront}, {LEDA}, {uC++}.

	{Usenet} newsgroup: {news:comp.lang.c++}.

	["The C++ Programming Language", Bjarne Stroustrup, A-W,
	1986].

	(1996-06-06)

A language proposed by Cii {Honeywell-Bull} to meet the DoD
	{Ironman} requirements which led to {Ada}.  This language won
	in 1979.

	["On the GREEN Language Submitted to the DoD", E.W. Dijkstra,
	SIGPLAN Notices 13(10):16-21 (Oct 1978)].

	(1994-12-02)

<programming> (Or "released version", "baseline") A version of
	a piece of software which has been made public (as opposed to
	a version that is in development, or otherwise unreleased).

	A release is either a {major release}, a {revision}, or a
	{bugfix}.

	Pre-release versions may be called {alpha test}, or {beta
	test} versions.

	See {change management}.

	(1996-08-04)

<storage> The part of a {disk} which passes under one
	read/write head while the head is stationary.  The number of
	tracks on a disk surface therefore corresponds to the number
	of different radial positions of the head(s).  The collection
	of all tracks on all surfaces at a given radial position is
	known a {cylinder} and each track is divided into {sectors}.

	(1997-07-15)

1. Not operating.  "The up escalator is down" is considered a
	humorous thing to say, and "The elevator is down" always
	means "The elevator isn't working" and never refers to what
	floor the elevator is on.  With respect to computers, this
	term has passed into the mainstream; the extension to other
	kinds of machine is still hackish.

	2. "go down" To stop functioning; usually said of the
	{system}.  The message from the {console} that every hacker
	hates to hear from the operator is "System going down in 5
	minutes".

	3. "take down", "bring down" To deactivate purposely, usually
	for repair work or {PM}.  "I'm taking the system down to work
	on that bug in the tape drive."  Occasionally one hears the
	word "down" by itself used as a verb in this sense.

	See {crash}; opposite: {up}.

	[{Jargon File}]

	(1994-12-07)