a_dent@fennel.cc.uwa.oz.au (01/10/91)
Some time ago I replaced the terminal emulation in NCSA Telnet (2.2) with Freedom One. This was using the MPW 2.02 environment. I was recently asked to do some fixup work, this time using MPW 3.1 (the client bought a new MPW - the old one belonged to a different company). To my utter horror (on a fixed-price contract that's *UTTER HORROR*) the changes to make MPW C ANSI compliant have far-reaching effects and we've just about given up on converting to MPW 3. (Waiting on a version that some poor soul has already converted, to see if worth re-applying my original changes). On enquiry, it seems that even the latest version from NCSA is still compiled with MPW 2.02 and I just tried compiling with MPW 2.02 today under System 6.07 with no ill effects. So, why change????? Just WHAT deadly, dark, evil incompatibility is lurking around the corner if we fail to convert this code to MPW 3? For anyone considering such a conversion, get the MPW C manual, read the appendix of changes, then read the front of the manual, then meditate on how many Str255 *'s you have, and how many string literal comparisons, and ... MPW 3 - JUST SAY "NO" (unless someone gives me a very good reason ;-) ) Andy Dent A.D. Software phone 09 249 2719 Mac & VAX programmer 94 Bermuda Dve, Ballajura a_dent@fennel.cc.uwa.oz Western Australia 6066 a_dent@fennel.cc.uwa.oz.AU (international)
ech@cbnewsk.att.com (ned.horvath) (01/11/91)
From article <1991Jan10.222325.2753@fennel.cc.uwa.oz.au>, by a_dent@fennel.cc.uwa.oz.au: > Some time ago I replaced the terminal emulation in NCSA Telnet (2.2) with > Freedom One. This was using the MPW 2.02 environment. ... > Just WHAT deadly, dark, evil incompatibility is lurking around the corner > if we fail to convert this code to MPW 3? > > For anyone considering such a conversion, get the MPW C manual, read the > appendix of changes, then read the front of the manual, then meditate on > how many Str255 *'s you have, and how many string literal comparisons, and > MPW 3 - JUST SAY "NO" > (unless someone gives me a very good reason ;-) ) Under your circumstances, I'd agree: just say no. The awful conversion you contemplate is due to sins Apple committed long ago in trying to "help" C programmers by converting pascal strings on the fly but still supplying the minimal glue, etc. I wouldn't bother to try to convert anything as large and ugly as NCSA Telnet unless the fellow behind me had a very large knife and a very short temper. For new projects, the 3.x compilers produce much better code, and support C++ in the bargain, in addition to redressing those old sins. Even there, I'd wait (now) for the 3.2 compiler to go final: the dump/load and other new features should be worth another couple months' wait. =Ned Horvath=
keith@Apple.COM (Keith Rollin) (01/11/91)
In article <1991Jan10.222325.2753@fennel.cc.uwa.oz.au> a_dent@fennel.cc.uwa.oz.au writes: >Some time ago I replaced the terminal emulation in NCSA Telnet (2.2) with >Freedom One. This was using the MPW 2.02 environment. > >I was recently asked to do some fixup work, this time using MPW 3.1 (the client >bought a new MPW - the old one belonged to a different company). To my >utter horror (on a fixed-price contract that's *UTTER HORROR*) the changes to >make MPW C ANSI compliant have far-reaching effects and we've just about >given up on converting to MPW 3. (Waiting on a version that some poor soul >has already converted, to see if worth re-applying my original changes). > >On enquiry, it seems that even the latest version from NCSA is still >compiled with MPW 2.02 and I just tried compiling with MPW 2.02 today under >System 6.07 with no ill effects. > >So, why change????? > >Just WHAT deadly, dark, evil incompatibility is lurking around the corner >if we fail to convert this code to MPW 3? > >MPW 3 - JUST SAY "NO" >(unless someone gives me a very good reason ;-) ) There are many reasons for changing. Whether or not they are good is up to you. Internally, one of the biggest reasons for our coming out with a 3.0 compiler was that we needed control. The previous C compilers were written by Green Hills, and we had no control over them. We didn't even have the source code. Whenever a bug was reported, we had no way of tracking it down or fixing it. This lack of control also extended to enhancments. For instance, we wanted an ANSI compliant compiler. We also wanted C to support the SADE symbol format. Neither of these enhancement could be made without a 3.0 version. From your point of view, the best reason for converting to 3.x would be when you wanted to program for some part of the system which was added after MPW 2.0.2 was released. For instance, you wouldn't be able to do any programming for 7.0 without an up-to-date set of interfaces and libraries. Also, support for SADE symbols is handy if you want to do source level debugging with either SADE or Jasik's debugger. The 3.x compiler is also better than 2.0.2 with regard to code generation and error detection. You get better error message closer to the actual error, warnings on variable usage, and code that is more optimized. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
aruigrok@bnr.ca (Adrian Ruigrok) (01/11/91)
In article <1991Jan10.190126.12521@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) writes: >> Just WHAT deadly, dark, evil incompatibility is lurking around the corner >> if we fail to convert this code to MPW 3? >> >=Ned Horvath= > The conversion was already done many months ago by Lawrence D'Oliveiro at Waikato University, Hamilton, NZ. I believe this version is labled as NCSA Telnet 2.4 Beta at Zaphod. My coworkers have hit a couple of bugs that we have not been able to isolate yet, but Lawrence has fixed up many other problems with it. If you are interested in an MPW 3.x version look at that one first... Adrian
daven@svc.portal.com (01/13/91)
In article <1991Jan10.222325.2753@fennel.cc.uwa.oz.au> a_dent@fennel.cc.uwa.oz.au writes: >To my utter horror (on a fixed-price contract that's *UTTER HORROR*) the >changes to make MPW C ANSI compliant have far-reaching effects and we've >just about given up on converting to MPW 3. >Just WHAT deadly, dark, evil incompatibility is lurking around the corner >if we fail to convert this code to MPW 3? > >For anyone considering such a conversion, get the MPW C manual, read the >appendix of changes, then read the front of the manual, then meditate on >how many Str255 *'s you have, and how many string literal comparisons, and > >MPW 3 - JUST SAY "NO" >(unless someone gives me a very good reason ;-) ) There may not be any compatiblity problems if you continue to use code compilied under MPW 2.x. What you will run into is that MPW 2.x will not run under System 7.0 or A/UX. MPW 3.x comes with several nice additions as well. Projector, the Mark Browser, split text views to name a few. Of these Projector is the most useful. -- ------------------------------------------------------------------------------- Dave Newman | daven@sv.portal.com | "Hacking only works so far before Software Ventures | AOL: MicroPhone | the tree begins to fall." Berkeley, CA | AppleLink: D0025 | - Rush Drake
urlichs@smurf.sub.org (Matthias Urlichs) (01/13/91)
In comp.sys.mac.programmer, article <47967@apple.Apple.COM>,
keith@Apple.COM (Keith Rollin) writes:
<
< The 3.x compiler is also better than 2.0.2 with regard to code generation
< and error detection. You get better error message closer to the actual
< error, warnings on variable usage, and code that is more optimized.
<
I agree -- MPW C 3.x has about the best error reporting I have seen.
With the exception of the "forgot to put a closing brace here" gotcha, that
is -- that one drives any C compiler crazy. :-(
I still wait for a compiler that will take indentation in account when
deciding what to do when it hits an error...
However, "more optimized" is relative. Compared to 2.0.2, you may be right.
Compared to gcc, however...
Don't forget that some of these error messages are quite funny. ;-)
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/laird@chinet.chi.il.us (Laird J. Heal) (01/13/91)
In article <47967@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article <1991Jan10.222325.2753@fennel.cc.uwa.oz.au> a_dent@fennel.cc.uwa.oz.au writes: [Note: there were alternative routines and header files posted to allow one to call the Trap calls avoiding the "glue" routines which did the string-conversions for us whether we wanted them or not; and there was a way, albeit painful, to convince the Green Hills C compiler to generate inline code for as many bytes as desired. Both of these were available since the days of the Lisa Workshop C compiler. There was not anything like \p for strings, though. Converting all of the string-converting calls is a straightforward, mechanical, onerous and non-trivial task; I only did it once, in 1985 I think.] >>So, why change????? >>[...] >>MPW 3 - JUST SAY "NO" >There are many reasons for changing. Whether or not they are good is up >to you. >Internally, one of the biggest reasons for our coming out with a 3.0 >compiler was that we needed control. The previous C compilers were >written by Green Hills, and we had no control over them. We didn't even >have the source code. Whenever a bug was reported, we had no way of >tracking it down or fixing it. Well, it is good to know that Apple does not ask more as a customer than it gives to its customers. This is not a flame. I would dearly love to have a CD-ROM with all of that wonderful source code MacsBug only hints at in the wee hours of the {AM,PM} whilst I wonder what that {OS,Toolbox} routine really is doing. How about it, a "Dark Side of the ROM" CD? Seriously, we have heard about Macintalk and now Green Hills C. It should show that there are some times when source code is than just useful, almost essential. Food for thought. Post any followups to misc.legal or something like that. Not seriously, let's light a little match for a second: you live by the sword, you die by the sword. Ooops, the flame died out: NAAH NAAH naah NAAH NAAH! (still not seriously) >Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support -- Laird J. Heal The Usenet is dead! Here: laird@chinet.chi.il.us Long Live the Usenet!
ksand@Apple.COM (Kent Sandvik) (01/14/91)
In article <1991Jan10.222325.2753@fennel.cc.uwa.oz.au> a_dent@fennel.cc.uwa.oz.au writes: >MPW 3 - JUST SAY "NO" >(unless someone gives me a very good reason ;-) ) What? And miss all the neato System 7 stuff? :-) Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "The ANSI C++ Standard should be an object oriented model"
ksand@Apple.COM (Kent Sandvik) (01/14/91)
In article <3037@ux.acs.umn.edu> dhoyt@vx.acs.umn.edu writes: >In article <1991Jan10.190126.12521@cbnewsk.att.com>, ech@cbnewsk.att.com (ned.horvath) writes... >>For new projects, the 3.x compilers produce much better code, and support >>C++ in the bargain, in addition to redressing those old sins. Even there, >>I'd wait (now) for the 3.2 compiler to go final: the dump/load and other >>new features should be worth another couple months' wait. > I aggree, but I would also suggest to get a copy of Gnu C for MPW as well. >The native C compiler is better for development, but the Gnu compiler is much >better at producing code; esp. when compiling C++ stuff. If I would be a commercial or semi-commercial developers I would try to ge my hands on as many C and C++ compilers available for the platform as possible - even if it would cost some money. The reason for this is that you could have different uses for each compiler, one produces good optimized code but is slow, others are good for fast rapid prototyping, and others have switches and tools that are neat to use during programming., The GNU C compiler is a very optimizing C compiler, and highly regarded in the development world. Just be careful and read the various manifestos before you eventually produce commercial code. Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "The ANSI C++ Standard should be an object oriented model"
ksand@Apple.COM (Kent Sandvik) (01/14/91)
In article <1991Jan13.112728.13613@chinet.chi.il.us> laird@chinet.chi.il.us (Laird J. Heal) writes: >There was not anything like \p for strings, though. Converting all of >the string-converting calls is a straightforward, mechanical, onerous >and non-trivial task; I only did it once, in 1985 I think.] > Well, another reason to switch to MPW 3(.2). The relase has a streamedit tool (sed style tool for you UNIX freaks) for mechanical editing of source code. Regards, Kent Sandvik -- Kent Sandvik, Apple Computer Inc, Developer Technical Support NET:ksand@apple.com, AppleLink: KSAND DISCLAIMER: Private mumbo-jumbo Zippy++ says: "The ANSI C++ Standard should be an object oriented model"
mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher) (01/14/91)
In article <48030@apple.Apple.COM>, ksand@Apple.COM (Kent Sandvik) writes: > The GNU C compiler is a very optimizing C compiler, and highly regarded in > the development world. I am disappointed, however, in GCC's poor code generated for multiplication with small integer constants. MPW C is much better in this respect. Matthias ----- Matthias Neeracher mneerach@iiic.ethz.ch "These days, though, you have to be pretty technical before you can even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_
keith@Apple.COM (Keith Rollin) (01/15/91)
In article <2$q6h2.y[6@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.sys.mac.programmer, article <47967@apple.Apple.COM>, > keith@Apple.COM (Keith Rollin) writes: >< >< The 3.x compiler is also better than 2.0.2 with regard to code generation >< and error detection. > >... "more optimized" is relative. Compared to 2.0.2, you may be right. >Compared to gcc, however... Could you finish that sentence? I'm eager to hear what experiences people have had with the MPW version of gnu C. I posted a little while ago that my own experiences included reducing an 83K program by only a single K or so. Given that gnu C takes about 3 times as long as MPW C to compile, this doesn't seem worth it to me. (Perhaps the resulting 81K program was also optimized for speed, which could explain why it wasn't vastly smaller than the MPW C version). -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions