[net.micro.mac] binary postings

guido@boring.UUCP (11/18/85)

In article <2237@amdahl.UUCP> ems@amdahl.UUCP (ems) writes:
>What about the new MacOwners who don't have all the binaries yet?  When
>I first got my mac, net.sources.mac was indespensable in making it
>a usable machine.

Macs are sufficiently widespread now that there better ways of getting
everyone a copy of the basic "hacks" than posting them to the net every
two months (like, user groups and knowledgeable friends in general).

>What about those who don't have a compiler yet?
>Those who don't want to lay out $N, where N is large, for M,
>where M is large, different environments/compilers?

The large M is indeed a problem.  Perhaps someone could post
	a) a list of differences between various compilers
	b) guidelines for writing "portable" Mac programs
	   [I'm not so naive that I believe in porting Mac applications
	   to other machines, even the ST or Amiga.  Peter da Silva,
	   are you convinced by now?]
	c) automatic conversion programs for certain compiler pairs
	   [shouldn't be too difficult to automate 90 percent of the
	   work; if it can be done for Fortran -> C it should be doable
	   for C -> C]
	d) [this is working in a very different direction]
	   the definite compiler review showing that we should all use
	   brand X
-- 
	Guido van Rossum, CWI, Amsterdam (guido@mcvax.UUCP)

chuq@sun.uucp (Chuq Von Rospach) (11/20/85)

> 	a) a list of differences between various compilers
> 	b) guidelines for writing "portable" Mac programs
> 	c) automatic conversion programs for certain compiler pairs

Well, there are three potential problems you run into, just looking at the
C compilers:

    o incompatible libraries - the different C compilers have implemented 
	the Toolbox interfaces using different capitalization schemes,
	so GetNextEvent() in Mac C may be getnextevent() in megamax. I
	think that they are slowly working towards fixing this, but some of
	the compiler writers evidently couldn't help "improving" on Inside Mac.

    o incompatible assemblers - different compilers support different forms
	of inline assembler, or don't support them at all. They have also
	developed their own object formats rather than standardizing on
	Apple's MDS format.

    o incompatible toolbox interfaces - This is the kicker. Some systems
	try to bury their toolbox interfaces, either by doing string
	conversions and other things within the library or using a special
	function calling (Sumacc hides the Toolbox incompatibilities as
	much as possible, Megamax uses a special pascal function definition
	type). Others (Mac C, for example) simply lets the programmer
	figure out how to do the interface with a small glue routine. 

At one point I was porting example from Sumacc to Mac C. The only place I
had any problem at all was where Sumacc and Mac C had different ideas of
talking to the Toolbox. Mac C lets the programmer do it, Sumacc tries to
help, and occasionally gets in the way because of it. I finally stopped due
to lack of time (I may finish it Real Soon Now) but not until I came to the
realization that these differences were enough that I couldn't just use an
ifdef to define between the compilers, and Sumacc and Mac C are quite close
to each other. I'm currently looking at rewriting SKEL into Mac C, but
it'll be from scratch instead of a port because there are major differences
in the details of the code. I don't see how that can be automated, offhand.

> 	d) [this is working in a very different direction]
> 	   the definite compiler review showing that we should all use
> 	   brand X

For C compilers, I like Mac C. Why? It was one of the first on the market.
It reads MDS assembler, meaning that you can use anything shipped out of
apple. It reads MDS object files, meaning you can use any of the Apple
supplied libraries (like MacinTalk). Version 4.0 has a new optimizing
linker that gets rid of dead code, meaning smaller applications. It also no
longer needs MDS, so you don't have to buy anything else to make it run,
so the cost isn't outrageous now. The Mac C people have also tried to not
improve on the Inside Mac definitions so you don't have to do as much
translation from the documentation to reality. There is also now a book out
called "Using the Macintosh Toolbox with C" by three guys from Berkeley
that is wonderful (review pending -- I just got it, but a mini-review is
"BUY IT. NOW.")

My second choice would be Sumacc, but everyone doesn't have access to a
good cross development environment. I've looked at a fair amount of Megamax
code, and I don't happen to like it because they've taken a lot of
liberties with toolbox names that give me headaches trying to convert back
and forth.

-- 
:From catacombs of Castle Tarot:        Chuq Von Rospach 
sun!chuq@decwrl.DEC.COM                 {hplabs,ihnp4,nsc,pyramid}!sun!chuq

Let us now take the sacre oath. As of now, he is no longer an elephant!

tim@ISM780B.UUCP (11/25/85)

> good cross development environment.  I've looked at a fair amount
> of Megamax code, and I don't happen to like it because they've
> taken a lot of liberties with toolbox names that give me
> headaches trying to convert back and forth.

Megamax has allowed IM toolbox names for a long time, if the programmer
wants to use them.

dave@rocksvax.FUN (Dave Sewhuk) (12/02/85)

/* rocksvax:net.micro.mac / tim@ISM780B.UUCP / 12:55 pm  Nov 25, 1985 */


>Megamax has allowed IM toolbox names for a long time, if the programmer
>wants to use them.

That is wrong!!  The syslib file has the names in lower case to link against.
I didn't have a hard disk at the time so I could not afford to have
their new 50K batch program or the ToolNames file or the convert program on
any disk and still have room for the sources, compiler and linker.

That may be an option if you have a big disk and are willing to waste time
whilst the machine converts your source to the lower case version for 
compiling.

Dave

arpa: Sewhuk.HENR@Xerox.ARPA
uucp: {ihnp4,rochester,amd,sunybcs}!rocksvax!dave
ns: "Sewhuk:HENR801C:Xerox".ns@Xerox.ARPA

rick@ut-ngp.UUCP (Rick Watson) (12/03/85)

>>Megamax has allowed IM toolbox names for a long time, if the programmer
>>wants to use them.

>That is wrong!!  The syslib file has the names in lower case to link against.
>I didn't have a hard disk at the time so I could not afford to have
>their new 50K batch program or the ToolNames file or the convert program on
>any disk and still have room for the sources, compiler and linker.

>That may be an option if you have a big disk and are willing to waste time
>whilst the machine converts your source to the lower case version for 
>compiling.

Perhaps you misunderstand.  You can use convert and toolnames to convert
syslib and all your .h files to mixed case.  You only have to do this once.
Then you write your applications in mixed case and compile and link
normally.

Rick Watson
University of Texas Computation Center
 arpa:   rick@ngp.UTEXAS.EDU   rick@ngp.ARPA
 uucp:   ...seismo!ut-sally!ut-ngp!rick   rick@ut-ngp.UUCP
 bitnet: ccaw001@utadnx
 phone:  512/471-3241

tim@ISM780C.UUCP (Tim Smith) (12/05/85)

me == >>

In article <-37000300@rocksvax.UUCP> dave@rocksvax.UUCP writes:
>>Megamax has allowed IM toolbox names for a long time, if the programmer
>>wants to use them.
>
>That is wrong!!  The syslib file has the names in lower case to link against.
>I didn't have a hard disk at the time so I could not afford to have
>their new 50K batch program or the ToolNames file or the convert program on
>any disk and still have room for the sources, compiler and linker.
>

You don't have to keep convert around.  You use it once to convert all the
names, and then forget it.  This is what I did before I got my hyperdrive.
Why can't you take a disk, but convert and batch and toolbox.names ( or
whatever it's called ) on it, copy over the files that need converson (
*.c, *.h, *.o, syslib, any libraries you have made ), convert them, and
copy them back?

For those who are not familiar with all this, here is an explanation of
what all this is about:

	As shipped, the names of all the toolbox routines in MegaMax C
	are all lowercase.  There is a program called "convert" that
	comes with the system.  It can take as an argument a .c or .h
	file, or a library of object files.  It reads a file, toolbox.names,
	or something like that, which contains the names of all the routines
	in mixed case.  "convert" fixes the .c, .h, and library symbol
	tables to contain mixed case toolbox names ( it can also be told
	to go the other way ).
-- 
Tim Smith       ima!ism780!tim || ihnp4!cithep!tim || sdcrdcf!ism780c!tim

bhyde@inmet.UUCP (12/05/85)

This is a little strong.  It took an hour on my, single drive,  128K
mac to convert the include files and system library in Megamax C to
mixed case from all lower case using the tools they provided.  The
Batch pgm, at that time, didn't work at all on a 128k machine.  When I
last talked to them they said it now did work on small tasks like
doing the convert. ben hyde. cambridge.