Hints for programmers: (updated 22-Oct-91) ========================================== !IMPORTANT NOTE FIRST! ---------------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Since V2.07 I supply the lmkfile I USE (before I supplied one, I just built for the distribution disk), because I don't want to hassle around with two different lmkfiles. I too often forget to adapt the second one after making changes to the first. The big differences between those two was: in the lmkfile I REALLY used, I use my own linker library (ex.lib) for certain small routines (Ellipse,Line...); in the lmkfile I SUPPLIED these routines were located in an extra file (extra.c). I did this to give owners of an Aztec-C-Compiler a chance to recompile the files. Meanwhile I use so many SAS/Lattice C specific things (e.g. __chip keywords), that I don't think any Aztec user will have much use of the source files. So to make life a bit easier for the SAS/Lattice owners (and for me too, of course), I now just supply the really used lmkfile AND the lib (ex.lib). I didn't have time to document it, yet, as soon as I have, I will distribute it on PD. All desperate Aztec users, who for some reason want to recompile the sources with their compiler can write in to me (i.e. send me a disk) and I will return the full source code (incl. the ex.lib source). !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Now the other interesting things: -------------------------------- First, all source files have been compressed into an archive (Source.LZH) using Lharc V1.30 (AmigaLibDisk 404). I have included Lharc V1.30 on my distribution disk. However I don't know if all PD-distributors leave it there, so you may be have to get elsewhere. All other (older) versions of Lharc should also work, though I have not tested them. All source files have been compiled with the SAS/Lattice C 5.10a Compiler. See below for problems concerning the optimizer! All files use 32-bit-integer variables so I hope there is no problem in this aspect. Besides source-file-specific headerfiles (*.h) which are located in the source root directory (on the same level as the *.c files they belong to), I provide all the needed header files for the req.library, the arp.library and the iff-saver (ilbmw.c). Because I now (since V2.07) provide also the source code of 'ConvM3D', I now store all source files with their pathnames. This will lead to problems during the compile process, because it is very unlikely that you use the same directory structure as I do. This causes problems when you compile certain files (for example ilbmw.c), because the include files are supposed to be located in a subdirectory (in this case iff/). You may either change the #include lines in the problematic files or you may create a subdirectory INCLUDE below the source root directory and include the -i option in the lmkfile at the CFLAGS. If you do so I recommend to organize the files as follows: source/ *.c source-files *.h other header files extra.c has to be moved from pdomain/ to the source root directory!!! lmkfile automatic compilation and linking if you use LMK, has to be moveded from pdomain/ to the source root directory!!! include/ clib/ req_protos.h libraries/ reqbase.h arpbase.h iff/ compiler.h gio.h iff.h ilbm.h packer.h proto/ arp.h mtwx_defs.h req.h convm3d/ convm3d.c main file for ConvM3D rev.c revision code for ConvM3D lmkfile automatic compilation and linking if you use LMK A lmkfile is provided, so Lattice users could simply type LMK and the compile process will run automatically (see below for the memory problem). **** PROBLEM: Unlike the old Aztec C Compiler (V3.6a), the SAS/Lattice C Compiler 5.10a needs a terrible amount of memory during the compilation process. I have great problems in compiling the main file (chemest.c) even though I've got 1 MByte RAM. I have to disconnect my external drive and switch off MachIII even though I place the quad file on my hard disk (-qdh0:). If anybody has a solution to this, please let me know. It seems to be a problem of the precompiler, because most of the memory has been eaten up before the real compilation process is started (I used SnoopDos to check this). What do the users with just 512 KByte do, Lattice ? It seems impossible to me that they can compile any program that #includes more than eight files. I will try to chop the chemest.c into several smaller files and #include exactly what is needed and won't use a (large) precompiled header file. Maybe this will do for a while, but this can't be the solution, Lattice. I hope there will be a solution with the next compiler release. I have some problems in writing a convenient message-receiving routine. Sometimes the GURU will visit you if you select a menu or close a window. I reduced the frequency of the Guru's appearance by using ARP's CloseWindowSafely() instead of Intuition's CloseWindow(), but it still happens sometimes. PLEASE: If anyone has a solution for this please let me know. I looked thru lots of computer magazines but I didn't find anything else than my Nachricht() (-> Message) routine. I use my own (well actually it comes from QuickReq.c from AmigaLibDisk457) _main() routine to get rid of that f***ing console window that is opened by all files compiled with the Lattice compiler (take that away Lattice, it must be up to the programmer to include this!). The console window that is now opened is my own (see OpenRevWin in extra.c) and I need it to display certain messages. By now I use the following routines outside of AmigaDOS, Intuition etc.: ArpAlloc arp.library CloseWindowSafely arp.library FileRequester req.library SimpleRequest req.library TwoGadgetRequest req.library SetLocation req.library ReadLocation req.library SetSize req.library I do not use the req.library's palette requester because it does not have all the things a good palette requester has to have. Instead I use Jonathan Potter's paletterequest(). Thanx Jonathan, it's old, but it's still the best! Do not change rev.c, as it has a special format that is needed by other files. All source files come with German comments and (partly) German names for routines and variables. If you would like to know what they mean, well, try learning German, it's a fascinating language. The newer files are ANSI-C compatible and they are compiled with the -ca option of the compiler. The current version is a mixture of ANSI and non-ANSI files, I intend to make ALL files ANSI compatible in the future. I intended to provide a makefile for Aztec C users and to embedd Lattice specific things in #ifdefs but I didn't have the time yet. If somebody does this, I would like to get a copy of this. If nobody does I may do it on my own somewhere in time... Let's wait'n'see! Some words about optimization: ------------------------------ Due to my lack of leisure time, I can't optimize the program as much as I want to, so I handed this over to the global optimzer GO (Option -O) of the SAS/Lattice C packet. Unfortunately, GO does seem to have some bugs. In the released version V2.06 the input of data is *NOT* possible, the program crashes while or before modifying the prop-gadget. While debugging (and for that removing the -O option), the error didn't occur. Same as with the palette requester. So I changed the lmkfile so that neither palettereq.c nor eingabe.c will be optimized. If you use your own lmkfile be aware of that. DON'T OPTIMIZE palettereq.c AND eingabe.c!! Have fun! Joerg P.S. None of the files may be touched, changed, deleted or distributed on own series of Stefan Ossowski PD-Versand, Rainer Wolf PD-Versand (OASE) and Markt & Technik Verlag AG, Greetinx to Bernstein Softworks (Risk, Dragon Cave) for their RIGHT attitude concerning some kind of PD distributors.