[comp.unix.aux] MacApp->C++->A/UX

jmm@skivs.UUCP (Joel M. Miller) (04/18/91)

MacApp, so far as I know, contains Object Pascal and requires Pascal
libraries, and so does not produce code that could be compiled by
cc under A/UX.

I suppose that the reason for providing MacApp for MacOS -- to make it
easier to write Mac-like applications than not -- applies to A/UX as well,
and so expect that Apple has provided, or soon will provide, a version
of MacApp using C++ instead of Object Pascal, along with the required A/UX
libraries.  So:

	++  If MacApp++ exists, how do I get it (beta`s welcomed)?
	++  If it is comming, when?
	++  If not, why not???

-- 
Joel M Miller                    Internet: jmm@skivs.ski.org
Smith-Kettlewell Institute       Usenet:   fernwood!skivs!jmm
2232 Webster St                  Bitnet:   jmm%skivs.ski.org@fernwood.mpk.ca.us
San Francisco, CA 94115          Voice:    415/561-1703     Fax: 415/561-1610

ksand@Apple.COM (Kent Sandvik) (04/20/91)

In article <3151@skivs.UUCP> jmm@ski.UUCP (Joel M. Miller) writes:
>MacApp, so far as I know, contains Object Pascal and requires Pascal
>libraries, and so does not produce code that could be compiled by
>cc under A/UX.

Sorry, a slight misconception, A/UX cc produces COFF files. MPW Pascal,
C, Asm and C++/C produces MPW object format files. Object classes that use
a special PascalObject C++ base class for their class hierarchies can
be linked with both Object Pascal and C++ code modules with the
MPW linker.

>I suppose that the reason for providing MacApp for MacOS -- to make it
>easier to write Mac-like applications than not -- applies to A/UX as well,
>and so expect that Apple has provided, or soon will provide, a version
>of MacApp using C++ instead of Object Pascal, along with the required A/UX
>libraries.  So:

The new MacApp 3.0 makes use of PascalObjects as the base class, in
order to create method tables (instead of the normal vtables) so 
people could use these classes/libraries from both Object Pascal and
C++ with the MPW linker. It has really nothing to do with A/UX - more
of a switch to C++ in order to build better class internals which are
not visible from the C++ or Pascal code.

>	++  If MacApp++ exists, how do I get it (beta`s welcomed)?

Just now a selected list of developers have access to the first alpha
version of MacApp 3.0. A later alpha release will be available from the
so called ETO CDs.

>	++  If it is comming, when?

Real soon now!

>	++  If not, why not???

Hmm, a better question would be "Are there any plans to support COFF
format from the MPW environment?", or "Will the A/UX linker support
linking of MPW object format files?", or "Will there be a MPW Shell
that runs on top of A/UX?, and similar questions :-).


Regards,
Kent Sandvik

-- 
Disclaimer: Private and personal activities on USENET, non-company sponsored

ksand@Apple.COM (Kent Sandvik) (04/22/91)

In article <GK7__1=@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>In comp.unix.aux, article <51729@apple.Apple.COM>,
>  ksand@Apple.COM (Kent Sandvik) writes:

>< Hmm, a better question would be "Are there any plans to support COFF
>< format from the MPW environment?"

>It's possible to convert COFF to MPW.

>The main problem is that due to the nonrelocatability of COFF code, if you
>want to link COFF stuff you have to put everything in data space (i.e.
>A5-relative). This includes the executable code.

Yes, a good example of binaries compiled under cc and moved to the 
MacOS environment are the tools under standalone shell. If you ever
wondered why your System/Finder won't start sash, well maybe an init
or something else that increases your system heap has taken over memory
space above about 639k (0x9FC00), and the modules require data addresses
starting from that point. So changing globals to use A5-relative offsets
is a must.

>Is there any good way to feed object code back into the assembler? Dumpobj
>isn't very good at producing reasemblable output. Maybe an additional option
>for dumpobj is in order here; it would certainly simplify things.
>Apple?

I have to talk with the DSG people - the idea is good. Maybe there's a
way, but I'm not aware of it.

Kent Sandvik

-- 
Disclaimer: Private and personal activities on USENET, non-company sponsored

ksand@Apple.COM (Kent Sandvik) (04/23/91)

In article <51781@apple.Apple.COM> ksand@Apple.COM (Kent Sandvik) writes:
In article <GK7__1=@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:

>>Is there any good way to feed object code back into the assembler? Dumpobj
>>isn't very good at producing reasemblable output. Maybe an additional option
>>for dumpobj is in order here; it would certainly simplify things.
>>Apple?

>I have to talk with the DSG people - the idea is good. Maybe there's a
>way, but I'm not aware of it.

Correction, actually the new streamedit tool (sed done Apple style) makes
it possible to take the output of dumpobj, strip any unneeded information
and feed it back as assembler code. streamedit is available from MPW 3.2
forward (ETO CDs, soon a real product from ADPA).

Kent

-- 
Disclaimer: Private and personal activities on USENET, non-company sponsored

esink@turia.dit.upm.es (Eric Wayne Sink) (04/24/91)

In article <51729@apple.Apple.COM> ksand@Apple.COM (Kent Sandvik) writes:
>
>Hmm, a better question would be "Are there any plans to support COFF
>format from the MPW environment?", or "Will the A/UX linker support
>linking of MPW object format files?", or "Will there be a MPW Shell
>that runs on top of A/UX?, and similar questions :-).
>
Good questions.  Anybody have any answers or even pseudoanswers ?

"Could it be that questions tell us more than answers ever do ?"
  -Michael Card

>
>Regards,
>Kent Sandvik

Eric


Eric W. Sink                     | "If no one is criticizing |Opinions
Departamento de Telematica       | your work, it is possible |mine -
Universidad Politecnica de Madrid| that you are not doing    |all of
esink@turia.dit.upm.es           | anything." -George Verwer |them.