| Volume Number: | 11 | |
| Issue Number: | 9 | |
| Column Tag: | Symantec Top 10 |
Symantec Top 10 
This monthly column, written by Symantec’s Technical Support Engineers, aims to provide you with technical information based on the use of Symantec products.
By Steve Howard
Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.
Q: What is MacApp?
A: MacApp is an object-oriented application framework from Apple Computer. Although MacApp has many similarities with the THINK Class Library, it is larger, more complex, and more modular in design. This flexibility has made it a popular tool in the Macintosh Programming community and has been used for programs like Adobe Photoshop, and RayDream Designer.
Q: What versions of MacApp are supported by the Symantec Project Manager?
A: The earliest supported MacApp version is 3.1.1. We recommend version 3.1.3 (distributed on ETO 17) because the examples and code will work without modification. MacApp 3.3a1, also on ETO 17, is a prerelease of the next major version and is basically the same as MacApp 3.1.3 except it adds support for AOCE, scriptability, and the Drag Manager.
Q: Where can I get MacApp?
A: Symantec has licensed MacApp from Apple and has included it on SDA #3. All non SDA customers must get MacApp from Apple Computer by purchasing it through APDA, as part of MPWPro or an ETO subscription. To order MacApp call APDA at 1-800-282-2732.
Q: What are the system requirements to install and run MacApp?
A: The Symantec C/C++ for MPW folder with the associated electronic documentation will require approximately 22MB of hard disk space. The latest MPW (3.3.1) will require 3.6MB and the prebuilt MacApp 3.1.3 system on the ETO CD-ROM takes up another 20MB. You’re looking at about 56MB of disk space that you’ll need free.
Both MacApp versions come with a project model for Symantec C++ for Power Macintosh which, by using the Symantec Project Manager frees developers from having to utilize the MPW shell. The Symantec C++ for Power Macintosh full installation folder requires 44.8MB of disk space which, added to the requirements of the prebuilt MacApp 3.1.3 system makes the free disk space needed 63MB. This requirement can be reduced by using the alternate installation of the Symantec C++ for Power Mac 8.0.
Apple recommends that you use a Macintosh system with at least 24MB of RAM for developing MacApp applications. Symantec recommends that the minimum partition for the Symantec Project Manager be 8000K with the preferred size being 12000K. You may want to increase the preferred sizes of the partitions depending on the size of the application you are developing.
Q: Are there any installation subtleties I need to be aware of?
A: To run MacApp 3.3a1 under the Symantec Project Manager there are a few changes you will need to make. You will have to install Drag.h and the AOCE headers and AOCE library. The process to install these are outlined in the Release notes provided on both SDA #3 and ETO #17.
There are also two errors in MacApp 3.3a1 that you will need to correct to compile with the Symantec Project Manager. In the file UDebugView.cp you will need to move the #if qDebug that is before the TDebugFlagsView class definition (around line number 92) to the top of the file, so it is before the first Include. Also in the file UGridView.cp, following the DoFulfillPromise member function (around line 2460), you will need to change #endif qDrag to #endif //qDrag. Both these files can be found in the libraries folder within the MacApp3.3a1 - HD Ready folder.
Be sure to read the Release notes and readmes provided with either SDA #3 or ETO #17. They provide information that is essential to you being able to successfully develop with MacApp and the Symantec Project Manager.
Q: What is SMrC/Cpp ?
A: It is the PowerPC compiler for MPW. It is compatible with MrC/Cpp. You can build MacApp with SMrCpp, instead of using MrCpp. As of ETO #17, you may have to rename the SMrCpp to MrCpp to trick MABuild to use SMrCpp for build. Then you would just use MABuild -cp MrC ......
Q: I want to weak link a shared library (e.g. QuickDrawGXLib.xcoff) to a project because I want my application to run even if the shared library is not present. How do I do this?
A: Bring your project up to date and double click on the shared library in your project window. (If you did not update the project before you double click on the shared library you will get an error “Could not complete the last command because the AppleEvent was not handled. Error = -1708”). Turn on the “Soft Import Binding” radio button. In this case your program should take care not to call any non-existent routine in the shared library.
Q: I am precompiling my header files and am getting the following build error:
File “TextUtils.h”; Line 311; While compiling “Mac #includes.c” Error: ‘stringtonum’ previously declared as something else
It was declared as: void C func(char const *, long *)
It is now declared as: void C func(char *, long *)
A: Go into the header file BDC.h in the 2.0a4 Universal Headers folder that you copied from the Symantec C++ for Power Macintosh CD-ROM and change the following code:
#ifdef CGLUESUPPORTED // defined in 2.0a4 or later
void stringtonum(const char *theString, long *theNum);
#else
void stringtonum(const char *theString, long *theNum );
#endif
to:
#ifdef CGLUESUPPORTED // defined in 2.0a4 or later
void stringtonum(const char *theString, long *theNum);
#else
void stringtonum(char *theString, long *theNum );
#endif
This is only a problem with the newer version of BDC.h that comes with universal headers 2.0a4
Q: Why are the structs in my PowerPC project a different size from those in my 68K project?
A: By default, the PowerPC compilers align fields within structs to 4-byte boundaries. The 68K C++ compiler, by default, will align the fields within structs to 2-byte boundaries. THINK C will always align fields within structs to 2-byte boundaries. 68000 chips must reference word or long values from even addresses. Therefore, the 68000 chip requires, at least, 2-byte alignment. More recent 680x0 chips do not have this limitation, but perform faster when referencing word or long values from even addresses. The 68040 and PowerPC chips perform even faster with structures aligned to 4-byte boundaries.
If you need to share data structures in memory between 68K and PowerPC code, or need to read or write a data structure from/to disk with both 68K and PowerPC code, you will need to enable the same type of alignment in both your 68K and PowerPC projects.
Q: I’ve heard that Symantec is going to make the THINK Reference compiler available to developers so they can create their own databases. When is that going to be available?
A: The THINK Reference compiler is not ready to be released to the developer population as of yet. If you are interested in becoming a beta tester for the THINK Reference compiler you can contact us here at technical support by email at: support@devtools.symantec.com or by calling: (503)465-8470 and we will be able to start the necessary processes to get you in our beta testing program.
Special thanks to Michael Hopkins, Yuen Li, and Kevin Quah.
