[comp.sys.mac.programmer] MacApp and MPW

gil@ginger.sri.com (Gil Porat) (12/01/89)

I'd like to upgrade my 2.0.2 MPW system (MPW, MPW Pascal,
MPW C) to MPW 3.0, but I'd like to keep MacApp 1.1.1.

Does anyone know whether or not MacApp 1.1.1 can be used
with the MPW 3.0 environment?

I would assume it is a straight forward conversion...just
recompile the universe.

Thanks,
Gil Porat
gil@rml.sri.com

keith@Apple.COM (Keith Rollin) (12/02/89)

In article <6298@unix.SRI.COM> gil@ginger.sri.com (Gil Porat) writes:
>
>I'd like to upgrade my 2.0.2 MPW system (MPW, MPW Pascal,
>MPW C) to MPW 3.0, but I'd like to keep MacApp 1.1.1.
>
>Does anyone know whether or not MacApp 1.1.1 can be used
>with the MPW 3.0 environment?
>
>I would assume it is a straight forward conversion...just
>recompile the universe.

Gil,

MacApp 1.1.1 is only supported under MPWs before MPW 3.0. There have been many
changes to the Pascal compiler that renders a lot of MacApp code illegal, all
of which need to be addressed in one way or another if you are too succeed in
your endeavor. Here is an excerpt of an article I wrote on that very subject:


Dear MacApp Developer,

In Developer Technical Support, we have noticed that a number of people are 
upgrading to MPW 3.0 and trying to use their MacApp 1.1.1 or 2.0'5 sources and 
Build system. Unfortunately, this doesn't always work too well, and some 
changes need to be made in order to get MacApp to compile.

DTS only supports the current versions of Apple software.  MacApp 1.1.1 was 
supported with MPW 2.0.2, and the final version of MacApp 2.0 will only be 
supported by MPW 3.0.  Basically, we're saying that using old MacApp with new 
MPW is not supported.  If you're under some time constraints, we recommend that 
you stick with what works and not to make the conversion of your MacApp program 
until you have all the latest versions.  

The supported configurations are:

    MacApp 1.1.1       use MPW 2.0.2
    MacApp 2.0'5       use MPW 2.0.2 or 3.0
    MacApp 2.0 final   use MPW 3.0 or later


Pertinent MPW 3.0 release notes.
===============================
If youUre an Object Pascal (MacApp) user you should know that the -Opt option 
requires an additional keyword argument: On (optimize), NoBypass (optimize but 
always dispatch - generate any direct JSRs), or Off (don't optimize - the same 
as not specifying -Opt).

If you're using MacApp 1.1.1 you can use the MPW 3.0 linker to generate 
optimized applications, but you'll have to update the -opt option command lines 
in the MacApp make files.  Several bugs in the optimizer have been fixed, and 
fewer jump table entries are used by optimized programs.  MacApp 2.0 will allow 
debugging of optimized programs.

Object Handle Warnings
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 
Previously, Pascal only gave a warning when an object field was passed as a 
VAR parameter.  Now Pascal will also give a warning when passing an object 
field that is greater than 4 bytes.  Part of MPW Pascal's calling convention is 
to pass a pointer for parameters larger than 4 bytes.  It is the callee's 
responsibility to make a copy of the parameter.  If the parameter is larger 
than 4 bytes and a field of an object (or handle), and the called routine is in 
an unloaded segment, the act of loading the segment could move the object and 
make the pointer to the parameter invalid.  Or, if the routine is a trap call 
that moves memory (see Appendix B of Inside Macintosh), the pointer to the 
parameter could be made invalid.

Change in the -h Option
The -h option, which turns off object (handle) warnings, used to be overidden 
by the {$H+} directive.  Now -h permanently turns off the warnings.  Turning 
off these warnings could be bad, so instead it's better to use the {$H+/-} 
directive.  Here's an example taken from the sample MacApp program "Calc" and 
its use of this directive.

PROCEDURE TCalcDocument.AddCell(theCell: TCell; 
                                  r: RowNumber; c: ColumnNumber);

   VAR
      aRect:            Rect;

   BEGIN
   fCells[r, c] := theCell;
   fAllocatedCells := fAllocatedCells + 1;

   SetRect(aRect, c, r, c, r);
{$Push}{$H-}
   UnionRect(aRect, fInUseBounds, fInUseBounds);
{$Pop}

   WITH theCell DO
      BEGIN
      fCalcDocument := SELF;
      fRow := r;
      fColumn := c;
      END;
   END;


"fInUseBounds" is a VAR parameter for _UnionRect.  The Pascal compiler will 
complain about a field of an object being used as a VAR.  But, we know that in 
this case it's a safe use of the object's field.  It won't move while this 
method is executing.

Known Bugs
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 
### Forward References for Objects
A unit with an unresolved object reference must be used before the unit that 
resolves the reference.  For example, Unit1 defines object Obj1 that has Obj2 
as a field, and Unit2 defines Obj2.  But Unit1 does not USE Unit2.  The main 
program must use Unit1 before Unit2 so Unit2 will know to patch up the 
unresolved reference.  If Unit2 precedes Unit1 in the uses clause, the 
reference will be left unresolved and an error will occur.

Work around:  Put units with unresolved references before units that resolve 
the references in the Uses clause.

### Forward Objects References in Programs
Any use of an object identifier before its declaration in a program (as 
opposed to a unit) will not work correctly.  It results in type-compatibilty 
and inconsistent-parameter-list errors.

Work around:  Move forward object references from the program into a unit.

### -sym Options
The -sym options novars, notypes, and nolines are only syntactically 
supported.  In fact, they do the same thing as -sym full.

Work around:  Lib and Link can be used to strip symbolic information.

### Symbolic Debugging & Object Pascal
Pascal doesnUt emit any type information about Objects for SADE.

Work around:  none



Using MacApp 2.0'5 with MPW 3.0
===============================
MacApp 2.0 was created under prerelease versions of MPW 3.0; when MacApp 2.0'5 
was released, the latest version of MPW was 3.0'1. However, there were many 
changes between the Beta release of MPW and the final, some of them affecting 
the compilation of MacApp programs. Fortunately, with just a few changes to the 
MacApp sources and build system, you can get working debug and non-debug 
versions of you application.

The following is a segment from the release notes that come with MPW 3.0. They 
have been included here as they appear on the disk for the sake of consistency. 
However, they contain a few errors. Corrected notes are included here.

In order to use MacApp 2.0'5 with this release of MPW 3.0, you will have to 
make the following changes to MacApp:

 1. In MacApp.opt.make2, change
            LINK I -OPT I
        to
            LINK I -OPT ON I

 2.  Make sure the MPW2 flag in MacAppStartup is set to False.

 3.  The 3.0 Pascal compiler has more complete checks for unsafe
     uses of objects. You will have to fix all the unsafe uses of
     objects flagged by the compiler in MacApp, the samples, and
     your programs or disable the compiler checking

 4.  The function method TGridView.IdentifyPoint uses the function 
     name IdentifyPoint in boolean expressions like:

        IF (IdentifyPoint = InColumn) THEN

     The 3.0 Pascal compiler correctly treats this as a recursive 
     call without enough arguments.  To fix this problem, declare 
     a local variable:

        tempPoint : GridViewPart

     and replace all references to IdentifyPoint in the function 
     body with tempPoint, and add a last line to the method:

        IdentifyPoint := tempPoint;

     * The MPW 3.0 release notes incorrectly state to change it to:
        tempPoint : GridPart

 5.  As mentioned in the release note regarding Types.r, there are
     new flags in the SIZE resource.  Here is a new SIZE resource
     for the Nothing sample:

        resource 'SIZE' (-1) {
            saveScreen,
            acceptSuspendResumeEvents,
            enableOptionSwitch,
            canBackground,
            MultiFinderAware,
            backgroundAndForeground,
            dontGetFrontClicks,
            ignoreChildDiedEvents,
            is32BitCompatible,
            reserved, reserved, reserved, reserved,
            reserved, reserved, reserved,
        #ifdef Debugging
            275 * 1024,
            250 * 1024
        #else
            128 * 1024,
            96 * 1024
        #endif
        };

     * This differs from the MPW 3.0 release notes documenting the SIZE
     resource to use the conditional "#ifdef Debug", but MacApp 2.0'5
     uses the name "Debugging."

6. Recompile _all_ of your MacApp sources, and create a new MacAppLib.o.
   Some of the library routines are now inline functions in the Pascal
   Interface files (e.g. SystemZone). Linking with the old MacAppLib
   with the new Pascal libraries with cause some unresolved references.

7. Recompile _all_ of your sources -- MacApp and application -- using -clean 
or 
   -rebuild. The precompiled symbol table format has changed between MPW 3.0'1 
   and MPW 3.0. Attempting to use the obsolete symbol table format under the 
   new MPW doesn't always work.



Using MacApp 1.1.1 with MPW 3.0
===============================
MacApp 1.1.1 was started a long time ago, and the latest development system it 
was created for was MPW 2.0.2. However, Apple hasn't done any testing on MacApp 
1.1.1 and MPW 3.0 or allocated any engineering resources to getting them to 
work together. This is mostly because we've been working on MacApp 2.0. 
However, Apple Testing has put together some instructions that are the minimum 
that needs to be followed in order to get MacApp 1.1.1 to compile under MPW 
3.0. As we understand it, some people have been able to follow them with 
dazzling results, while other use them and are no better off. Creating 
non-debug versions of applications has been met with a partial success rate; 
making debug versions has not worked at all.

Briefly, these are the things you'll have to do just to get MacApp 1.1.1 to 
BUILD with MPW 3.0. We have no additional information about execution problems. 
 The following instructions are the only information we do have on getting old 
MacApp and new MPW working together.
 
1. Change SIZE Resource as shown above in the MacApp 2.0 notes.
 
2. Add the following module aliases in MacApp.make1, as they appear in
   MacApp 2.0:
 
    LinkDebug = -la
       -ma EqualString=equalstring
       -ma WWFACCESS=wwFAccess
       -ma WWCLOSE=wwClose
       -ma WWREAD=wwRead
       -ma WWWRITE=wwWrite
       -ma WWIOCTL=wwIoctl
 
3. Alias PASCAL to PASCAL -MBG CH8 -H

4. Change LINK -OPT to LINK -OPT ON, in MacApp.opt.make2

5. Replace 'watchCursor' with 'theWatch' in UMacApp.a


Hope this helps,

-- 
------------------------------------------------------------------------------
Keith Rollin  ---  Apple Computer, Inc.  ---  Developer Technical Support
INTERNET: keith@apple.com
    UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith
"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions