Frozen Fish 1: Amiga/FrozenFish-Apr94.iso/bbs/alib/d5xx/d571/gwin.lha/Gwin/Changes

Text File | 1991-12-22 | 12KB | 192 lines

This is a change history of GWIN

Release 1.0  - Initial Version

Release 1.1  - Maintenance Version

   1.  New Aztec Manx 5.0 compiler/linker is incompatible with earlier
   versions of object code.  Everything must be recompiled including
   my GWIN object files gwin.ff.o, gwin.ffCD.o, and gwin.fiCD.o.  You
   need these new release 5.0 versions if you are using the 5.0 compiler
   because the old object files will not link with object files created
   using the new version of the compiler.   Many thanks to Adam Benjamin
   of Michigan for bringing this to my attention.  I had not realized that
   there was a problem until he called.  I had been dragging my feet with
   respect to getting the new compiler since I always try to avoid early
   versions of software - Particularly compilers and operating systems.
   So now I have version 5.0b.  (Or is it c?  My disks came with the "b"
   scratched out and a "c" printed by hand.)  I recompiled GWIN and that
   is the primary reason for redistributing the software.

   2.  Due to a book-keeping error on my part, the LATTICE-related
   object codes included on fish disk 322 (gwinl.ff.o, gwinl.ffCD.o,
   and gwinl.fiCD.o) were not the versions I intended to include.
   They represent a slightly earlier version.  Glen Fullmer did a lot
   of work creating the Lattice versions of the GWIN object files and
   I blew it by not including the correct and most current version.
   My apologies to Glen and to all you other Lattice users.  The version
   on 322 was functional unless you tried to use the global variables
   in gwin.user.h.  At least one of my examples used the globals.
   The examples compiled and linked correctly for Glen back in Feb 89.
   He checked them out again for me today. Everything works if you use
   the versions on this disk.  Thanks to Stephen L. Ferrell of Pittsburgh,
   Pa. for bringing this problem to my attention.

   3.  Modified the uprint and uprnt1 text handling routines to handle
   complement modes so that you can handle text like rubber-band lines
   are handled.  (Essentially sets the XOR mode within the INTUITEXT
   structure if uset("comp") is in effect.)

   4.  Modified umove routine to handle the uset("ncli") operation more
   logically.  The rubberbandbox demo had a problem when the border was
   included.  The problem was that the umove routine was in effect applying
   clipping when it should not have been.  This has been corrected.



Release 2.0 - Amiga shared library version.

   1.  GWIN was converted from a collection of object routines that you
   linked in with your program to an AMIGA shared library.  AMIGA libraries
   reside in sys:libs and are automatically loaded into system space when
   they are opened by a call to OpenLibrary.  (In GWIN, the USTART macro
   performs the OpenLibrary calls for GWIN-required libraries so you
   don't have to worry about it.  The macro UEND closes the libraries so
   you also don't have to worry about THAT.)  The advantages of GWIN being
   an AMIGA shared library are these:

      a.  Your object code modules are much smaller.  GWIN is not linked in
      with your program.

      b.  Since GWIN does not have to link in with your program, we no
      longer have to worry about vendor changes to the object module
      formats.  We kept having a problem with incompatibility of new object
      module formats produced by new versions of the MANX and LATTICE
      compilers.  The new object modules would not link with the old
      object modules distributed on the Fred Fish disks.  It was
      impossible to keep up.  An AMIGA shared library does not care which
      version of whose compiler you are using. This means that LATTICE and
      MANX users should now be on an equal footing with respect to GWIN.
      GWIN should now work for everyone.  My good friend and associate,
      Glen Fullmer checked out the LATTICE interface.  He provided the
      LATTICE-specific makefile in the examples directory that shows how
      compiling and linking works using the LATTICE compiler.  Note that
      there is also a LATTICE specific include file in that directory whose
      name should be changed if you are a LATTICE user.  See gwin.doc for
      documentation regarding that.  Dave Kinser also helped check out the
      LATTICE interface.  Thanks Dave and Glen.

   The disadvantages of GWIN being an AMIGA shared library are these:

      a.  Creating AMIGA shared libraries is no fun.  They are difficult to
      create - or they were.  The answer for me was in the "Premiere issue"
      (April/May 1991) of "The AmigaWorld Tech Journal" in the article by
      Jim Fiore entitled "Shared Libraries for the Lazy" which discusses
      LibTool.  LibTool came on the disk with the magazine.  Still took a
      fair amount of effort but cut the time required by a factor of 10 in
      my opinion.

      b.  The complexity level of the GWIN routine calls was increased
      slightly.  I don't like this because the whole point of GWIN is to
      make things easier to use.  I have tried to minimize the complexity:
      the USTART and UEND macros hide the opening and closing of AMIGA
      libraries since I feel that you shouldn't have to worry about them.
      You do have to worry about USING the macros however.  If you use
      capital letters for USTART and UEND, you will get the macros.  I also
      had to include a structure pointer called "G" as the first parameter
      of each GWIN procedure call.  "G" points to a structure whose storage
      is created with a malloc within the GWIN routines.  This structure
      contains all of the GWIN graphics system values such as current
      color, uset and upset settings, etc.  In the gwin.user.h include
      file, I have given you access to a subset of the actual structure.
      (The actual structure is larger.)  The G structure is necessary
      because shared libraries are "reentrant" code, i.e., you can have
      several GWIN applications running simultaneously, each sharing the
      library. For this to occur, ALL of the volatile global program data
      and parameters for each user program must be kept separate.  G
      contains this data.  Please look at the examples in the examples
      directory to see how things should be used.

      c.  Since you no longer link GWIN in with your code, my ABORT routine
      is no longer active in your program.  This means that YOU will have
      to handle your own user-aborts.  Be sure to call UEND if you do your
      own abort handling after USTART has been issued.

      d.  I cannot, from within an AMIGA library, fully process the
      WINDOWCLOSE event.  The ugrin routines now return a zero if no
      WINDOWCLOSE event occurred and a "4" if a WINDOWCLOSE event did
      occur.  If you see the "4", it means you should issue UEND and assume
      that the graphics session was ended by the user.  (I can't do it
      because GWIN is no longer linked in with your program.  I have no
      direct control over your program, i.e., I cannot make your program
      exit.)


   2.  Color registers 15 and 31 are no longer restored to their default
   color of red when the uset(G,"ncom") command is executed. The active
   register (15 or 31 depending on the number of colors allowed by the
   screen type you are using) is now left with the value of whatever color
   was last drawn using complement mode (see uset(G,"comp") command).  This
   allows rubberband and xor text to continue to be the color you selected
   and were drawing in prior to execution of a uset(G,"ncom") command.
   Before this change, the uset(G,"ncom") command would snap items being
   drawn using complement mode back to red.

   3.  Jerome Santini of France wrote to say that he was unhappy that we
   did not consider the PAL users in Europe.  He said that if I would look
   on page 19 of my "Amiga ROM Kernal Manual:  Libraries and Devices", that
   I would see a discussion of PAL and, in particular, the variable
   GfxBase->NormalDisplayRows.  I looked on page 19 of my copy (Addison
   Wesley, 1986, and found nothing about PAL.  Apparently the manuals
   printed in Europe contain different information than the manuals printed
   in the USA.  I checked all my manuals for references to PAL and found no
   references except in the "Amiga System Programmer's Guide", Data Becker,
   1988, and found a tiny bit of information about PAL on page 78 but
   nothing about GfxBase->NormalDisplayRows.  I have to conclude that
   the text of manuals sold in europe and the text of manuals sold in the
   USA are different.  I drove to my local dealer and he had no new manuals
   and no further information regarding PAL.  So to our European friends I
   would like to say that we would have accomodated you in the first
   release of GWIN but manuals printed in this country are apparently
   different from manuals printed in Europe.  It is difficult to design to
   accomodate the PAL standard if our manuals do not mention it.  Anyway,
   I think I have managed to include PAL support in this release.  See the
   GWIN documentation under "ustart" to see how I attempted to do this.  I
   have been unable to test it however so please write if there is a
   problem.  If there is a problem, you might consider sending me a page or
   two of your manual describing GfxBase->NormalDisplayRows because I still
   do not know precisely what value it contains on PAL machines or what the
   maximum normal high-res limits are on PAL machines (512 or 625???)...
   Thank you Jerome Santini for writing to mention this problem.

   4.  Uend now, as one of its last tasks, attempts to allocate 10
   Megabytes of memory.  It cannot of course but the system doesn't know
   that up front and releases all sorts of memory that it has tied up but is
   not using.  In particular the memory associated with disk fonts.  I
   found it annoying that memory checks after running a GWIN application
   seemed to indicate that all memory was not restored to its original
   state.  Now it is.  This is essentially a cosmetic change but I couldn't
   stand it like it was.  I also free the 10 megabyte block IF the system
   WAS somehow able to allocate it so there are no loose ends...

   5.  In order to have compatibility with the LATTICE compiler, I had to
   make ugrinl, ugrinc, ugrina, and uigrina a little more complicated.
   The LATTICE compiler uses index register a4 as the base address register
   of procedures.  When I use a function pointer to call back one of your
   user-selected menu functions, the ugrinl, ugrinc, ugrina, or uigrina
   pragma sequence has not completed so the index registers have not been
   restored.  If I use register a4 while in the pragma, chaos results when
   the user-selected menu procedure attempts to execute.  I restricted
   usage of the registers to a0 through a3 and passed the event type and
   the keystroke via a structure.  See the documentation regarding ugrinc
   to see how to handle this.  All examples have been updated to reflect
   this change.  Glen Fullmer discovered the incompatibility and made it
   possible for me to isolate the source of the problem and develop the
   work-around.  Thanks again Glen.

   6.  The current compiler versions that the library was tested with were
   MANX AZTEC C Version 5.0e and SAS/Lattice C Version 5.10b.  You probably
   need to have a compiler that is at least as recent as these versions to
   be sure that the pragma support is available.