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.