Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!spool.mu.edu!cs.umn.edu!thelake!steve From: steve@thelake.mn.org (Steve Yelvington) Newsgroups: comp.sys.atari.st Subject: Re: Re: GEM source code Message-ID: Date: 9 Apr 91 21:58:06 GMT References: <1991Apr9.123634.12778@cbnewse.att.com> Organization: St. Croix Valley C and Ski Lines: 37 [In article <1991Apr9.123634.12778@cbnewse.att.com>, hofmann@cbnewse.att.com (james.r.hofmann) writes ... ] > Awhile back a request was made for people on the net to release > examples of working GEM code for use as a tutorial to those trying > to learn how such code works. A good idea, but I have one question. > Aren't the include files that come with a compiler proprietary? > That being so, I can post the source (set to compile with Prospero C) > but not the include files. That would not be all that helpful. Unless the Prospero people have lost their good sense, their .h files should be interchangable with anybody else's .h files. I haven't used Prospero, but I have looked at the manual, and their GEM libraries seemed conventional. Of course, you should post any .H files written for the application, including .H files generated by a resource editor. GEMFAST (for Sozobon, Alcyon and assembler) uses a single GEMFAST.H file in lieu of the standard obdefs.h and gemdefs.h files. The portable solution (on a system using GEMFAST) is to install files bearing the standard names but consisting of the following lines: #ifndef GEMFAST_H #include #endif If a lot of GEMFAST-dependent code starts showing up, it may be worthwhile to write a GEMFAST.H file that #includes the standard files and #defines fsel_exinput if your compiler lacks that binding. ---- Steve Yelvington / P. O. Box 38 / Marine on St. Croix, MN 55047 USA INTERNET: steve@thelake.mn.org UUCP: plains!umn-cs!thelake!steve GEnie: S.YELVINGTO2 Delphi: YELVINGTON