home *** CD-ROM | disk | FTP | other *** search
/ Mac-Source 1994 July / Mac-Source_July_1994.iso / C and C++ / Utilities / Winter Shell 1.0d2 / Documentation / Porting < prev    next >
Encoding:
Text File  |  1994-01-19  |  5.3 KB  |  67 lines  |  [TEXT/TeSt]

  1. -- Porting to MPW
  2.  
  3. This document describes the modifications that would be necessary to port the code for use under MPW.
  4.  
  5. - Makefile
  6.  
  7. THINK C uses special project files to coordinate compilation, but for MPW you will have to create a Makefile. The file "Test.π.map" contains a link map for the application, including a list of the files needed to compile the test application. You can use this as a basis for a source file list for a Makefile. Unfortunately, manually determining ".h" dependencies is a daunting task, and I'd recommend using some automatic tool to extract the information from the source files, if only I knew of such a tool. At least you can compile without specifying the ".h" dependencies, though you'll have to be careful to ensure that the appropriate ".c" files are recompiled if you modify any ".h" files.
  8.  
  9. - Segmentation
  10.  
  11. Except for the main segment it doesn't matter how the program is divided into segments. The main segment must contain the Macintosh interface glue libraries (in THINK C, these are called MacTraps and MacTraps2) and the following files:
  12.  
  13. AlertFakeLib.c
  14. ApplicationLib.c
  15. ExceptionLib.c
  16. insort.c
  17. LowMemLib.c
  18. main.c
  19. MemoryLib.c
  20. PatchLib.c
  21. qksort.c
  22. SegmentLib.c
  23. TrapLib.c
  24. VBLTaskLib.c
  25.  
  26. The file "SegmentLib.c" may require modification if the format of MPW's jump table differs from that described in IM-II. If you want automatic unloading of segments you must ensure that the compiler generates a stack frame (LINK/UNLK instructions using register a6) for each compiled function. In THINK C this is specified with a pragma directive; I don't know what option controls this behavior in MPW. You must also ensure that all routines whose address is taken (e.g., call-back routines, comparison routines for sorting, etc.) have jump table entries generated for them. In THINK C this is handled automatically, but I don't know whether MPW generates external references for functions whose address is taken but which are accessed only from within a single segment. To disable automatic unloading of segments, change the initial value of gUnloadEnable to false in "SegmentLib.c".
  27.  
  28. - File prefix and precompiled headers
  29.  
  30. In THINK C it is possible to define a prefix which is automatically included at the start of every compiled file. For MPW, you'll have to modify the source files to include the following two lines at the top of the files:
  31.  
  32.     #pragma load "precompiled"
  33.  #include "CommonLib.h"
  34.  
  35. The file "precompiled" must be a precompiled header compiled from the file "Precompiled.c". (THINK C supports precompiled headers, and I'm fairly sure MPW does since the source to Disinfectant 2.4 includes such a pragma directive). The modifications can be accomplished automatically using MPW's utilities.
  36.  
  37. You should also define RELEASE_LEVEL to be one of the following constants (defined in the file "ReleaseLib.h"):
  38.  
  39. /* Product release levels. The release level determines how much debug     code
  40.     is compiled and what compiler optimizations are enabled. */
  41. #define RELEASE_DEV            (1)    /* all of debug code, no optimization */
  42. #define RELEASE_ALPHA        (2)    /* less debug code, some optimization */
  43. #define RELEASE_BETA            (3)    /* even less debug code, more optimization */
  44. #define RELEASE_FINAL        (4)    /* no debug code, full optimization */
  45.  
  46. You can define RELEASE_LEVEL with a -D compiler flag. If RELEASE_LEVEL is not defined it defaults to RELEASE_DEV. At least for the first compilation I recommend using RELEASE_DEV since this enables all assertions, which may help catch porting problems.
  47.  
  48. - Assembly language
  49.  
  50. While I've tried to limit use of assembly language, there are some places where its use just seems inevitable (e.g., trap patch glue). You can easily find all assembly language code by searching for the keyword "asm". You should also search for constants that start with the string "ASM_". While these constants should not require modification for MPW you should take a look at their uses (there aren't many) and verify that they will work under MPW. Other than short bits of assembly language (10 lines or less), the only fairly long assembly language code is in the file "PatchLib.c", where it is used as glue between the trap dispatcher and the patch routine.
  51.  
  52. - Floating point
  53.  
  54. There is very little floating point code. The only file which may cause problems is "FloatLib.c", which contains functions for converting between strings and floating point numbers.
  55.  
  56. - Integers
  57.  
  58. MPW uses 4-byte ints while THINK C uses (by default) 2-byte ints. This should not be a problem since both compilers use 2-byte short ints, and I have been careful to use short ints wherever a Toolbox call requires a 2-byte value.
  59.  
  60. - ANSI
  61.  
  62. The file "ANSI-stubs.c" contains a few short stubs which in THINK C help reduce the amount of code needed by stubbing out unneeded libraries. This file may require modification for MPW.
  63.  
  64. - Profiling
  65.  
  66. Profiling tends to be fairly compiler specific. Every compiler writer seems to want to provide their own set of profiling tools. If you want to do profiling, define PROFILE as 1 and search the code for its uses to determine if the code requires modification for profiling under MPW. One area which may cause problems is the exception handling code, which uses longjmp to handle an exception. In THINK C, the profiler maintains a stack of functions and it was necessary to modify the profiler by adding a "profiler depth" variable to keep track of the profiler's function stack.
  67.