Microsoft vs Lindows

From: Eric Smith <eric_at_brouhaha.com>
Date: Wed Aug 14 02:49:00 2002

> Here's the text from a 1978 Business Week article. Note the quote from
> "Billy Gates":

Fascinating. Inspired by that, I looked up another reference to a
computer supporting text windows:

Apple II Reference Manual, January 1978, Apple Computer Inc., page 74:

    Hex BASIC Example Description
    ---- ------------- -----------

[...]

    TEXT Mode Controls
    ------------------
    0020 90 POKE 32,L1 Set left side of scrolling window
                                      to location specified by L1 in
                                      range of 0 to 39.

    0021 100 POKE 33,W1 Set window width to amount specified
                                      by W1. L1+W1<40. W1>0

    0022 110 POKE 34,T1 Set window top to line specified
                                      by T1 in range of 0 to 23

    0023 120 POKE 35,B1 Set window bottom to line specified
                                      by B1 in the range of 0 to 23. B1>T1

A few pages later, this is followed by the source code to the "Apple II
System Monitor" which implemented the windowing, and had a 1977 copyright.

The next edition, titled "APPLE ][ REFERENCE MANUAL", was first published
in 1979. Page 31 has a more detailed explanation of the windowing feature:

    BUT SOFT, WHAT LIGHT THROUGH YONDER
    WINDOW BREAKS!

    (OR, THE TEXT WINDOW)

    In the above discussions of the various motions of the output cursor,
    the words "right", "left", "top", and "bottom" mean the physical right,
    left, top, and bottom fo the standard 40-character wide by 24-line
    tall screen. There is, however, a way to tell the COUT subroutine
    that you want it to use only a section of the screen, and not the
    entire 960-character display. This segregated section of the text
    screen is called a "window". A program or language can set the
    positions of the top, bottom, left side, and width of the text window
    by storing these positions in four locations in memory. When this is
    done, the COUT subroutine will use the new positions to calculate the
    size of the screen. It will never print any text ouside of this
    window, and when it must scroll the screen, it will only scroll the
    text within the window. This gives programs the power to control the
    placement of text, and to protect areas of the screen from being
    overwritten with new text.

    Location number 32 (hexadecimal $20) in memory holds the column
    position of the leftmost column in the window. This position is
    normally position 0 for the extreme left side of the screen. The
    number should never exceed 39 (hexadecimal $27), the leftmost [*]
    column on the text screen. Location number 33 (hexadecimal $21)
    holds the width, in columns, of the cursor window. This number is
    normally 40 (hexadecimal $28) for a full 40-character screen. Be
    careful that the sum of the window width and the leftmost window
    position does not exceed 40! If it does, it is possible for COUT to
    place characters in memory locations not on the screen, endangering
    your programs and data.

    Location 34 (hexadecimal $22) contains the number of the top line of
    the text window. This is also normally 0, indicating the topmost line
    of the display. Location 35 (hexadecimal $23) holds the number of the
    bottom line of the screen [**] (plus one), thus normally 24
    (hexadecimal $18) for the bottommost line of the screen. When you
    change the text window, you should take care that you know the
    whereabouts of the output cursor, and that it will be inside the new
    window.

[*] Presumably they meant "rightmost".
[**] Presumably they meant "of the text window".

Note that neither manual explicitly discusses the concept of having
multiple windows on the screen simultaneously, although the first
paragraph in the newer manual suggests that when it proposes using
the feature to "protect areas of the screen from being overwritten with
new text." The earliest game program I wrote for the Apple ][ (in
Integer BASIC), back in late 1977, took advantage of this feature to
display multiple windows for different aspects of the game, and even
used inverse-video space characters to create visible borders for
the windows. The utility of multiple independent text windows was
readily apparent to even a novice programmer. Since the Apple monitor
would only keep track of one window and cursor location, it fell upon
the application programmer to track multiple sets and swap the relevant
values in and out of the zero page variables used by the monitor
($20-23 for window bounds, 24-25 for cursor location, and 28-29 for
current line base address (or call VTAB at FC22 after switching)).

As anyone who used the Apple ][ extensively will tell you, many programs
did use multiple windows, although only a few programs presented
overlapping windows. Most were tiled, but at least a few allowed
overlap in a limited manner. The most common form of overlap that I
recall seeing in Apple II programs was the creation of a new window
overlapping existing information in order to prompt the user for some
input, akin to a "dialog box" in modern GUIs.

And the window concept on the Apple ][ wasn't limited only to text.
One of Apple's Contributed Software Library disks included a character
generator program for high-resolution graphics mode, and it honored
the window settings. I recall playing at least one game in 1978 that
used this feature.

Note that Microsoft Windows 1.x *only* supported tiled windows, and
presumably Microsoft would not claim that their "Windows" trademarkdid not apply to Microsoft Windows 1.x.

Anyhow, even though this usage of windows on a computer display dates
back to mid-1977, it's fairly clear that other such uses existed in
the 1960s.
Received on Wed Aug 14 2002 - 02:49:00 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:36 BST