lerner@isi-vaxa.ARPA (Mitchell Lerner) (10/22/85)
I need a good development environment for Macintosh machines. Does a clean, easy to use (I'm used to 4.2bsd's C) C development support exist for the Mac? Please respond If you know of one which would be fairly painless to develope a little database engine with on a 512k Mac. Will the library routines be simular in form and power to 4.2's? I need to develop a small, interactive, menu driven, database and I really dont want to use BASIC!!! Thanks, Mitchell
bc@cyb-eng.UUCP (Bill Crews) (10/26/85)
> I need a good development environment for Macintosh machines. Does a clean, > easy to use (I'm used to 4.2bsd's C) C development support exist for the > Mac? Please respond If you know of one which would be fairly painless > to develope a little database engine with on a 512k Mac. Will the library > routines be simular in form and power to 4.2's? I need to develop a > small, interactive, menu driven, database and I really dont want to use BASIC! > > Mitchell The latest Byte Magazine (November?) contains yet another comparison of C compilers, this time for the Macintosh. It appeared to me (and to the reviewer, I think) that Manx's Aztec compiler was quite nice. It presents a Unix-like shell environment for development, and allows developed programs to use the shell OR one of two levels of interface to Macintosh tools. I'm not a Mac jock, yet, so I can't elaborate too well. One BIG gotcha, however . . . it is copy-protected! Yes, even though it is a software tool, it is copy- protected! I try to boycott that practice. That is why I don't use Micro- soft Word for PC work. -- - bc - ..!{seismo,topaz,gatech,nbires,ihnp4}!ut-sally!cyb-eng!bc (512) 835-2266
dave@lsuc.UUCP (David Sherman) (10/27/85)
See the fairly detailed comparison of five such packages
in the current (November 1985) BYTE.
Dave Sherman
The Law Society of Upper Canada
Toronto
--
{ ihnp4!utzoo pesnta utcs hcr decvax!utcsri } !lsuc!davejdb@mordor.UUCP (John Bruner) (10/30/85)
[I'm cross-posting this to "net.micro.mac" and directing followups to that newsgroup only.] Before I start, I'd like to say that if you are used to developing C programs on UNIX, using the Mac will be a big step down. It is *slow*. It is *painful* (beware of leaving your source discs in the Mac when running your program -- in several cases a program crash due to an uninitialized pointer has caused my Mac to freak out and trash my discs). The Toolbox doesn't handle errors very well (e.g. DrawPicture on a still-open picture will produce a disc- destroying crash). [Much of this is to be expected, given the difference in hardware between (say) a VAX with Fujitsu Eagles and a non-MMU micro with floppy discs. I hope affordable micros with memory management start showing up in the marketplace soon.] The November 1985 issue of BYTE does have a lengthy comparison of Macintosh C compilers. The author favors the Manx Aztec C development system. The Manx product is a good one; however, I believe that the review was somewhat unfair to the Megamax compiler. (I use the Megamax compiler, but I have no other connection with Megamax, Inc.) One point which argues against the Megamax compiler (and which was understated in the review) is that it defines "short" integers to be 8 bits wide. This is contrary to the conventional practice in other compilers (and will be in violation of the ANSI standard when that standard becomes available). This is a serious "misfeature" and I wish Megamax could be persuaded to fix it. A big factor in favor of the Megamax compiler is the lack of copy protection. This has made their development system very flexible. A second major factor is price. The review compares the most expensive development system available for each of the five compilers it covered. The difference between the (undiscounted) prices of the Megamax compiler and Aztec developer's system is $200. It was unfair to cite the RAMdisc compile time of the Aztec C compiler without providing similar figures for the other compilers. Perhaps the other compilers do not come with RAM discs, but for $200 (the difference in price between the Aztec developer's sytem and the Megamax system) one can purchase all of the available RAM discs for the Macintosh (some are even public domain). The lack of copy-protection on the Megamax compiler probably enables it to use the RAMdisc more effectively than the Aztec compiler can. One negative assertion about the Megamax system -- the lack of sources for the library routines -- is untrue. The sources can be purchased for (I believe) $75. ($375 is still cheaper than $500.) I have found Megamax to be an good company to deal with. With the exception of short integers, I'm [obviously, I guess] a satisfied user of their product. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!seismo!mordor!jdb
rubin@mtuxn.UUCP (Mike Rubin) (10/30/85)
Manx has decided to remove copy-protection from Aztec C for the Mac. I just ordered a copy from my local computer store, and the salesman said the new version was unprotected. Score one for our side! :-)
daw@houxs.UUCP (D.WOLVERTON) (11/01/85)
Great, I'm glad to hear that Manx is dropping copy protection from its Mac C compiler. Considering the compiler's performance in the November BYTE article comparing C compiler's I'm going to get me a copy pronto.