Originally, the kill command could only kill a process, only later was kill enhanced to allow you to send any signal.
Since version 7 of Unix (1979) the default has been to signal the process in a way which can be caught and either handled gracefully or ignored (by sending a SIGTERM signal), but it can also be used to pull the rug out from under a process (a kill -9 sends a SIGKILL signal which cannot be caught and thus cannot be ignored).
Background
Computing, and Unix in particular, is rife with metaphor.
The main metaphor for processes is that of a living thing which is born, lives and dies.
In Unix all processes except init have parents, and any process which spawns other processes has children. Processes may become orphaned (if their parent dies) and can even become zombies, if they hang around after their death.
Thus, the kill command fits in with this metaphor.
Unix Archaeology
From the manual page from version 4 of Unix (the version where kill was introduced, along with ps) we find:
NAME
kill - do in an unwanted process
SYNOPSIS
kill processid ...
DESCRIPTION
Kills the specified processes.
The processid of each asynchronous process
started with `&' is reported by the shell.
Processid's can also be found by using ps (I).
The killed process must have
been started from the same typewriter
as the current user, unless
he is the superuser.
SEE ALSO
ps(I), sh(I)
I particularly like the final section of this man page:
BUGS
Clearly people should only be allowed to kill
processes owned by them, and having the same typewriter
is neither necessary nor sufficient.
By the time fifth edition had come around, the kill command had already been overloaded to allow any signal to be sent.
From the Unix Programmers Manual, Fifth Edition (p70):
If a signal number preceded by "-" is given
as an argument, that signal is sent instead of
kill (see signal (II)).
The default though was to send a signal 9, as signal 15 did not yet exist (see p150).
With version 6 the kill man page no longer mentioned the same typewriter bug.
It was only with version 7 of Unix that signal 15 was introduced (see see the signal(2) and kill(1) man pages for v7) and kill switched to that rather than using signal 9.
The term comes from assembly language. I can't verify the etymology, but my guess is that the name comes from the other use of the section. Whereas the .data section denotes variables that can change during the course of execution, the .text section contains data that doesn't change during execution, allowing it to be put into ROM if needed. That makes it useful for code, yes, but also makes it useful for strings of text that don't change. That's probably where the term came from.
To address Griffin's comment about first class functions, consider the following python 3 code:
def counter():
x = 0
def increment(y):
nonlocal x
x += y
print(x)
return increment
The code you actually execute for increment ends up looking internally something like:
self.func_dict['x'] += y
print(self.func_dict['x'])
That executable code can be put into ROM. It never changes throughout the execution of the program, no matter how many times you call counter(). What does change is the self pointer and its member variables. Those must be put into .data. When you return increment, you are actually returning a new instance of an increment function object. You are not dynamically creating new executable code every time. The code itself is immutable even though the pointer to it is not.
The only code that must be stored in the .data section is that generated by eval(), because it is not known to the compiler or JIT compiler at the start of the program. However, even that code is immutable. If you change the string and call eval() again, you're not changing the code from the previous time you called eval(), you're creating a whole new set of code.
Although the programming model may make it kind of feel like code is mutable, actual self modifying code at the processor instruction level is dangerous and rarely found outside OS voodoo topics like process context switching.
Best Answer
Back in the time of Windows 3.1, before Windows 95, you dragged the window, but it did not move. You were only moving an outline of the window, in form of semi-transparent frame. Only when you ended the drag, the window moved (jumping to final position; back then there were no graphics accelerators, so redraw of a window was expensive operation; resize worked similarly).
In Windows 95, one of the big things was, the window actually moved / resized while you were dragging it / its resizing border. Much nicer.
Well, those two WM_XXX messages are tied to dragging the movement frame (now invisible, but still present as a principle) vs. moving the actual window itself. I hope now it is clearer.