Window systems started with the Dynabook project at Xerox PARC. The Idea was taken from there by apple engineers and commercialized in the Apple Lisa and Macintosh. From there is has grown to MS Windows, X, Open-Look, and OS/2.
All the window systems listed above have movable overlapping windows, but this is not the only possible way. It possible to have the system control the display and management of windows by resizing the existing windows and shrinking them as more windows are added. Emacs uses this method for giving the user multiple views.
Emacs with tiled windows in a screen of overlapping windows
The ability to overlap windows has both advantages and disadvantages. More information can be displayed, but the windows can be buried beneath other more recently used windows. There are two solutions to this problem, one is get a bigger monitor, but this only works for so long as users will expand their document to fill the space. The other common solution is virtual windows of some sort. Card and his co authors, in 1984, called the concept "rooms", where each room has a different purpose and layout of windows. This can be achieved in UNIX with a window manager such as "tvtwm" or "fvwm".
A control from Fvwm to switch between virtual windows.
Windows themselves can be directly manipulated by the user. the have scroll bars for shifting the view of the content of the window if the content is too large for the window. There is a title bar to display the name of the window and provide a place for additional controls such as buttons for resizing and iconifying the window.
The controls of the windows, often called widgets, vary in placement between windowing systems and even different users configurations of the same window manager, so let the people who jump from platform to platform beware. Macintosh for instance doesn't allow windows to be iconified, while MS Windows and most X windows managers do.
One crucial issue when dealing with multiple windows is where the input from an external device goes. Pointers are fairly simple since they have a direct representation on the screen, usually in the form of an arrow. The keyboard however is a different story. It is inconvenient to have an arrow hovering over the text being input, so the mouse should be allowed to be moved away from the cursor. But at the edge of the window what should happen; and here there are two schools of thought. Click to focus gives a steady window for input and the user must click on a different window to change it. In Follow to focus the keyboard input is directed to the window below the mouse pointer.