mark@intek01.UUCP (Mark McWiggins) (07/01/88)
We're porting a system from the Unix/DOS world to the Mac, and I was rather shocked to find out about this 32K limit on global data. Our system contains > 64K, and we'd really like not to have to do any more rewriting than necessary. So: I understand that Aztec C does not impose this restriction, and that it works with MPW. Does it have another fatal flaw, or do those of you who use it find it satisfactory? Are there other possible choices for someone in our position? I saw a note to the effect that this subject has been beaten to death here recently, so I apologize for bringing it up again. I'm new to this group, though. If you want to send E-mail, I'll summarize for the net. Thanks in advance. -- Mark McWiggins UUCP: uunet!intek01!mark DISCLAIMER: I could be wrong. INTERNET: intek01!mark@uunet.uu.net (206) 455-9935
dxjsb@dcatla.UUCP (07/01/88)
Mark McWiggins writes: > So: I understand that Aztec C does not impose this restriction, and that > it works with MPW. Does it have another fatal flaw, or do those of you > who use it find it satisfactory? Are there other possible choices for > someone in our position? Well, My biggest problem with Manx/Aztec C is their inability to properly support the product. I've been a user since the product was originally released by in the summer of 1984. The current version is 3.4b, and has been out for a year now. It suffers several problems, most notably it generates errors whenever you try to declare a pointer to a Pascal function anywhere but in global memory. Since the product has not been upgraded for a year, it does not have support for MultiFinder or any of the other features introduced in the System 5.0 release (much less 6.0!). Manx has promised an upgrade since last fall, but have yet to deliver. It is obvious that they place much higher priority on their Amiga and Atari products than on the Mac stuff. I bet they have also seen their Mac sales drop off over the last several years, due to the emphasis being elsewhere. I wonder how they would do in the other markets given some competition. Actually, Aztec C is not all that bad. It still has features that no one else has, such as the ability to get Assembler code from the compiler. It produces nice, tight, fast code. If you are used to UNIX, you will prefer it interface, which is an adaptation of the Bourne shell (This also means scripting among other things). It has a _VERY_ complete set of support utilities that are very UNIX-like. It also will do what you want, under their "Large Machine" states. If they ever can get version 3.6 (and even, dare we hope, 4.1???) released and shipping, it should be a very good system. As you can see, my problem is not with their compiler/system, which I very much like, but in their inability to properly support that system. We (Brincomm Technology) plan to switch to MPW as soon as 3.0 is released. Good luck, Jack Brindle.
drc@dbase.UUCP (Dennis Cohen) (07/04/88)
In article <6319@dcatla.UUCP>, dxjsb@dcatla.UUCP (Jack S. Brindle) writes: > Mark McWiggins writes: > > Well, My biggest problem with Manx/Aztec C is their inability to > properly support the product. I've been a user since the product was > originally released by in the summer of 1984. The current version is 3.4b, The current version, the one I've had for about eight or nine months is 3.6A. I understand that more is on the way, but they don't seem real good about sending out upgrades and notices. The Shell still doesn't run properly on a color system, but all that really seems to be wrong is that there is inconsistent updating of the "screen color", which is really the desktop pattern. It is, however, totally incompatible with MultiFinder, although the libraries have code to allow you to write MF friendly applications. Dennis Cohen Claris ------------ Disclaimer: Any opinions expressed above are _MINE_!
kucharsk@amdahl.uts.amdahl.com (William Kucharski) (07/14/88)
In article <402@dbase.UUCP> drc@dbase.UUCP (Dennis Cohen) writes: >In article <6319@dcatla.UUCP>, dxjsb@dcatla.UUCP (Jack S. Brindle) writes: >> Mark McWiggins writes: >> >> Well, My biggest problem with Manx/Aztec C is their inability to >> properly support the product. I've been a user since the product was >> originally released by in the summer of 1984. The current version is 3.4b, ^^^^ >The current version, the one I've had for about eight or nine months is 3.6A. ^^^^ Where did you get 3.6A? When I ordered my copy of Aztec C in May (something I now pretty much write off as a "live and learn" experience) they sent me 3.4b. So either Manx was nasty and sent me an older version, or somehow you got a copy of an update. My biggest Aztec gripes: 1) Color <> Mac II problems. Manx says it will be taken care of "not in our next update, but the one after that" 2) If Pyro! activates itself while you're in "Z" upon returning the program crashes and dumps itself into MacsBug 3) Control Panel items (cdevs) are not available unless you put the Shell in the System Folder and start from there - otherwise it won't find any when you pull down the Control Panel 4) The example programs aren't written real well - some leave large white areas behind a window when a window is moved, and "Explorer," a DA for searching through RAM, has a typo that gives an extra character in the title bar of its window 5) No aliasing in the shell. If you want "rm -i" to be your default rather than just "rm," you can't do it. 6) The screen uses a different typeface and size than the editor. Therefore, when you "cat" something it won't look the same as it does in the editor. (To get around this, I wrote a "more" routine which sets the typeface to the same type and size as used by the editor). Basically, their interface is something you have to kind of "get along with." All I can say is "try before you buy." -- William Kucharski ARPA: kucharsk@uts.amdahl.com UUCP: ...!{ames,decwrl,sun,uunet}!amdahl!kucharsk Disclaimer: The opinions expressed above are my own, and may not agree with those of any other sentient being, not to mention those of my employer.
dxjsb@dcatla.UUCP (Jack S. Brindle) (07/14/88)
In his followup, kucharsk@amdahl.uts.amdahl.com (William Kucharski) writes: > Where did you get 3.6A? When I ordered my copy of Aztec C in May (something I > now pretty much write off as a "live and learn" experience) they sent me 3.4b. Don't give up yet! I just got version 3.6B yesterday. All I can say is "Oh my..." They have done a pretty nice job on this one. Two shells come with the package, the standard Aztec Bourne shell, and the MPW shell! Almost every Aztec utility will run under both (except the Z editor and the older db debugger). The C compiler now produces code that is compatible with that from the MPW system, meaning you can actually use both systems together? OK, before someone says why, try getting the assembler code from MPW C. Now drop that nice -a option on the Aztec cc line. MUCH easier! And, yes I do a lot of hand compacting of code. It's actually easier that fresh assembler, and runs quicker than the C generated code from ANY C compiler. The Aztec compiler now uses MPW C's header files, which means that getting updates may almost be as easy as getting an MPW header update, unless new glue is needed. In short, support problems notwithstanding, Aztec C is still a system that is worth looking at and working with. We have, however picked up MPW. The two systems seem to work together. Jack Brindle.