eberard@ajpo.sei.cmu.edu (Edward Berard) (09/15/88)
I have a number of remotely related questions. They all center around,
or are inspired by the segment loader.
1. There is a program (Sample.p) which comes with MPW. Near the
begining of this program there is a line that reads:
PROCEDURE _DataInit; EXTERNAL;
Where is _DataInit documented?
2. Later in the same program, there is a procedure call:
UnLoadSeg(@_DataInit);
This is, of course, documented in Inside Maintosh (II-59). What
are the C and the assembly language equivalents of this Pascal
call?
3. A number of the segment loader routines are clearly labeled:
[Not in ROM]. In terms of upward compatibility, and portability,
should a programmer be concerned about these routines? Are there
any other considerations?
4. Some people have informed me that they are not happy with the
upper bound of 32K. They have said that they might want to write
their own segment loader which did not have the fixed upper
limit of 32K. Assuming such a thing is possible, what problems
should they anticipate? Is Apple doing anything in Version 7.0
of the System which would mitigate, or otherwise impact such an
effort? Are there accptable alternative approaches? Is the 32K
limit still practical given the every expanding memory
capabilities of the Macintosh product line?
-- Ed Berard
(301) 695-6960levin@bbn.com (Joel B Levin) (09/16/88)
_DATAINIT is documented at least a little in the MPW manual chapter
"Advanced programming tools" under "more about linking" and "segments
with special treatment". See also the assembly manual under
"Programming for the Macintosh" in chapter 1. There may be something
in the C manual, but I couldn't find it. (These are the beta manuals;
the real ones are at home.)
The C syntax is:
extern _DataInit ();
. . .
UnloadSeg (_DataInit);
Don't worry about the [not in ROM] stuff. The libraries get it right.
In C you may have a choice of using the C interface or the Pascal
interface, depending on how you name routines. If an argument is a
string, for instance, the Pascal interface avoids the c-string to
p-string conversion. For Toolbox calls the Pascal version gets you an
in-line trap; for system calls that pass arguments by registers, you
get a different glue routine. If you are using C, Earle Horton wrote
a nice set of definitions (originally to help with incompatibilities
between THINK C and MPW) which let you easily use the simpler Pascal
interface to the toolbox. (let me know if you want a copy -- Earle
posted it once, so I guess I can distribute it :-)).
/JBL
UUCP: {backbone}!bbn!levin POTS: (617) 873-3463
INTERNET: levin@bbn.comech@poseidon.UUCP (Edward C Horvath) (09/17/88)
From article <369@ajpo.sei.cmu.edu>, by eberard@ajpo.sei.cmu.edu (Edward Berard):
! I have a number of remotely related questions. They all center around,
! or are inspired by the segment loader.
! 1. There is a program (Sample.p) which comes with MPW. Near the
! begining of this program there is a line that reads:
!
! PROCEDURE _DataInit; EXTERNAL;
! Where is _DataInit documented?
It's not. DataInit is responsible for getting constants (string and other)
that reside "below A5" in your application properly set up. Naturally there
IS NO below A5 in DAs, which is why initialized data is so hard to deal with
there when you use MPW.
! 2. Later in the same program, there is a procedure call:
! UnLoadSeg(@_DataInit);
! This is, of course, documented in Inside Maintosh (II-59). What
! are the C and the assembly language equivalents of this Pascal
! call?
UnloadSeg should be in the runtime library distributed with your C compiler.
See the Segment Loader in IM-2 for assembler details. Of course, this is
an attempt to free the segment containing the DataInit call. Make sure you've
not linked it into CODE 1...
! 3. A number of the segment loader routines are clearly labeled:
! [Not in ROM]. In terms of upward compatibility, and portability,
! should a programmer be concerned about these routines? Are there
! any other considerations?
Generally you CAN call UnloadSeg (and it is so in ROM!) but do not want to
call LoadSeg. LoadSeg is trapped to automatically when you call a routine
in an unloaded segment, and it COMPLETES THE SUBROUTINE CALL when it's done.
If you want to preload a segment, use GetResource ('CODE', segnumber).
! 4. Some people have informed me that they are not happy with the
! upper bound of 32K. They have said that they might want to write
! their own segment loader which did not have the fixed upper
! limit of 32K. Assuming such a thing is possible, what problems
! should they anticipate? Is Apple doing anything in Version 7.0
! of the System which would mitigate, or otherwise impact such an
! effort? Are there accptable alternative approaches? Is the 32K
! limit still practical given the every expanding memory
! capabilities of the Macintosh product line?
Aztec C will build larger-than-32K segments. The problem is that there is
only a (signed!) 16-bit offset in the jump table for each entry point in the
segment, so that LoadSeg alone will not properly set up the jump table for
entries which are more than 32K into the segment. The solution is a fairly
difficult to manage hack that requires the collaboration of the linker.
The Aztec linker is willing to go along with the gag (I should know!) but
you may have difficulty convincing Apple to do likewise with the MPW linker.
=Ned Horvath=
Disclaimer: I used to work for Manx...