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.