home *** CD-ROM | disk | FTP | other *** search
/ CP/M / CPM_CDROM.iso / beehive / utilitys / swdemo15.arc / SWIND1.ME < prev    next >
Text File  |  1991-08-11  |  9KB  |  229 lines
  1.  
  2.                      SWIND Windowing Library
  3.                           Eugene Nolan
  4.                Copyright 1989, All rights reserved
  5.  
  6.                          ***************
  7.                          * What is it? *
  8.                          ***************
  9.  
  10.   For changes from version 1.0, search for %%%
  11.  
  12.   SWIND (Small WINDows) was developed to fill the need for a fast, 
  13. compact, PORTABLE mechanism offering basic 'windowing' capabilities 
  14. across a wide range of computer systems.
  15.  
  16.   The basic design goals were speed, portability, device independence,
  17. and device simplicity.
  18.  
  19.   SWIND can be ported to any type of computer system that has a 
  20. good "C" compiler available. Included in this demo release are versions
  21. for CPM and the IBM PC/XT/AT family. Besides the system 'dependence'
  22. and 'critical' routines  ( both described below ), the main source code
  23. is identical for both of these systems.
  24.  
  25.   SWIND makes very few demands upon the host system. All window 
  26. functions are contained within the library. There is no special 
  27. runtime environment, and the requirements of the display device are 
  28. merely clearing the screen and positioning the cursor. SWIND 
  29. provides the capability of using attributes on a displayed element, 
  30. but if the output device is not capable of attributes, that is ok 
  31. also.
  32.  
  33.   SWIND interfaces to the host system thru a dependence routine that 
  34. is unique to each class of system it is run on. It is here that the 
  35. device specific functions are handled. This routine must provide an 
  36. entry point for:
  37.  
  38.    1:  Clearing the display
  39.    2:  Position the cursor w/ display of element/attribute
  40.    3:  Position the cursor
  41.    4:  Display of element/attribute
  42.  
  43.   Associated with the 'display of element' is the actual info to be 
  44. written to the display, along with it's attribute. It is the 
  45. responsibility of the dependence routine to manage the presentation 
  46. of the attribute to the display device. As an example, it would be 
  47. very expensive in I/O overhead on a serial/parallel device to 'set' 
  48. the attribute for each character, but rather to manage it on a 'has 
  49. it changed' basis, and if it has, to only then send the change to 
  50. the output device.
  51.  
  52.                       *********************
  53.                       * How does it work? *
  54.                       *********************
  55.  
  56.   SWIND is written in the "C" language, with select routines coded 
  57. in assembler to provided enhanced operation, based upon the system 
  58. it is to be run on.
  59.  
  60.   SWIND is NOT a terminal emulator written in "C", but rather a data 
  61. base manager whose resultant output is a visual image of the current 
  62. state of the data base.
  63.  
  64.   The paragraph above on the interface to the host system talks 
  65. about display of element, but makes no restrictions on what an 
  66. 'element' is. A definition of an element in SWIND is a single screen 
  67. position that can be uniquely addressed. In the Demo, that happens 
  68. to be configured as a character on a display device, but SWIND 
  69. itself does not set that restriction. The SWIND system itself has 
  70. the limitation of 32k elements, which should not pose itself as much 
  71. of a limitation (except on available memory!).
  72.  
  73.   SWIND REQUIRES a fixed amount of storage for each window that will 
  74. be used. The minimum number of windows is two, and the maximum is 
  75. based upon the type of system it is to be used on.
  76.  
  77.   For each window, three pieces of information are needed for each 
  78. display element: it's current value, attribute, and order of 
  79. precedence in display. See the information below on individual 
  80. systems to see how this information is stored.
  81.  
  82.   SWIND reserves window 0 as a background. This window cannot be 
  83. re-sized or hidden, but all other operations are applicable.
  84.  
  85.                 *********************************
  86.                 * Virtual Terminal Capabilities *
  87.                 *********************************
  88.  
  89.   Besides the basic window functions of position in display and 
  90. display of element, there is included in the SWIND library a set of 
  91. routines that provide a fairly sophisticated emulation of a terminal 
  92. type device that can be applied to a window.
  93.  
  94.   This routine provides the following 'escape' codes:
  95.  
  96.    1: Insert line
  97.    2: Delete line
  98.    3: Erase to beginning of line
  99.    4: erase to end of line
  100.    5: erase window
  101.    6: Set attribute value
  102.    7: Position cursor
  103.    8: Cursor up
  104.    9: Cursor down
  105.   10: Cursor left
  106.   12: Cursor right
  107.   13: Reverse line feed
  108.  
  109.   And the following low level codes:
  110.  
  111.    1: Carriage return
  112.    2: Line feed
  113.    3: Tab
  114.    4: Backspace
  115.    5: Delete character left
  116.  
  117.   The 'escape' codes to implement these functions are the same 
  118. across all systems. This provides a generic virtual terminal whose 
  119. capabilities are identical no matter what machine the library is run 
  120. on.
  121.  
  122.  
  123.              ***************************************
  124.              * Implementation on different systems *
  125.              ***************************************
  126.  
  127.   The basic implementation on different types of systems was based 
  128. upon such things as available memory, basic processor and and 
  129. operating system resources.
  130.  
  131.  
  132.                   1: CPM 2.2 and it's compatibles.
  133.           --------------------------------
  134.  
  135.   A Z80 compatible processor is required.
  136.  
  137.   Compared with the mainstream machines of today, these systems 
  138. posed the most challenging aspect of the design. A usual non-banked 
  139. system has limited resources, the biggest being available memory. A 
  140. usual system with vanilla components ( CCP/BDOS/BIOS ) or one that 
  141. has been manually installed comes in with about 55k of TPA. With the 
  142. advent of the NZCOM system installation , this may drop in the range 
  143. of 52k ( may be higher, depending upon the level of sophistication 
  144. of the systems owner/installer).
  145.  
  146.   The SWIND library routines are available in both Microsoft .REL 
  147. and SLR systems .REL format. There are no extra libraries required, 
  148. and the assembler to "C" interface is very straight foreword ( please
  149. see examples in SWFTNS.ME ).
  150.  
  151.   SWIND for CPM is auto-configuring as to terminal capabilities. If 
  152. it is run in a Z3 environment, the system TCAP is used, if not, a 
  153. user supplied imbedded TCAP is accessed.
  154.  
  155. %%% SWIND has been expanded to allow applications program to choose
  156. between using the proposed TCAP with full business graphics support, or
  157. defining the characters to use for border vertical/horizontal lines,
  158. and corners. The selection is made by linking with a different
  159. supplied library.
  160.  
  161.   The basic modules for this type system are configured for a 
  162. terminal type device, IE: character oriented, with limited attribute 
  163. capabilities. This system requires two  byte wide arrays for each 
  164. window, one holds the character data, and the other holds 5 bits of 
  165. info for attributes and 3 bits of info used for order of precedence 
  166. of display information.
  167.  
  168.  This provides for up to 8 windows, with each window requiring 3840 
  169. bytes ( 80 col X 24 rows X 2 arrays).
  170.  
  171.  There are seven critical internal routines coded in assembler. This 
  172. provides, in most operations, an I/O bounded system. SWIND can run 
  173. as fast as your terminal can accept the data, no matter how fast 
  174. your processor speed is. 
  175.  
  176.  SWIND uses 'smart' algorithms to keep the amount of I/O actually
  177. performed to a minimum. This also provides for enhanced through-put.
  178.  
  179.  
  180.                    2. IBM PC and compatibles
  181.            -------------------------
  182. %%% SWIND has been expanded to allow applications program to 
  183. define the characters to use for border vertical/horizontal lines,
  184. and corners.
  185.  
  186.  
  187.  
  188.   SWIND is currently available in Microsoft C 5.1 .OBJ format. This 
  189. requires the application's developer to have access to this compilers
  190. libraries to perform the link function.
  191.  
  192.   The basic modules for this type system are configured to run on 
  193. any of MONO/CGA/EGA display adapters. This system can be configured for
  194. either the two array ( as in CPM above ) or three internal byte wide
  195. arrays, one holds the character data, one holds 8 bits of info for
  196. attributes, and the third holds the order of precedence of display
  197. information.
  198.  
  199.  This provides for up to 256 windows, with each window requiring 
  200. 6000 bytes ( 80 col X 25 rows X 3 arrays).
  201.  
  202.  There are two critical internal routines coded in assembler. This 
  203. provides even more performance than that as available in max 
  204. optimized mode of the compiler.
  205.  
  206.  There is also a dependence routine provided that supports an ANSI 
  207. type device thru one of the PC's serial ports.
  208.  
  209.  
  210.                  3. Use on mini and/or systems
  211.                     providing queued device drivers
  212.             -------------------------------
  213.  
  214.   SWIND is also available in "C" source code form with a dependence 
  215. routine that provides internal and user routines with a method of 
  216. buffering output. This scheme substantially reduces the number of 
  217. operating system output requests required, with a substantial 
  218. increase in through-put.
  219.  
  220. %%% SWIND has been expanded to allow applications program to 
  221. define the characters to use for border vertical/horizontal lines,
  222. and corners.
  223.  
  224.   All internal routines that require more than a single output 
  225. function will automatically make the required dependence routine 
  226. calls to turn on buffering and the subsequent calls to display the 
  227. buffers built.
  228.  
  229.