CDTAXW@IRISHMVS.BITNET ("Mark B. Johnson") (06/04/87)
Just a note that APW C has shipped ... just got mine today - only been waiting 7 months. Mark
rms@meccsd.UUCP (06/07/87)
In article <8706031851.aa09659@SMOKE.BRL.ARPA> CDTAXW@IRISHMVS.BITNET ("Mark B. Johnson") writes: >Just a note that APW C has shipped ... just got mine >today - only been waiting 7 months. Hope you won't be too disappointed. A couple of guys from here went to the GS college a couple weeks back and pretty much decided that the the thing is useless. (E.g., will generate code approximately twice as large as comparable 65816 code. Which is no surprise if you ask me). Currently, APW C (read Megamax C) isn't fully K&R. Roger Shimada rms@MECC.MN.ORG ihnp4!meccts!rms
nick@drutx.ATT.COM (SilvaN) (06/29/87)
Well, the APW C for the //GS is finally available from APDA. So far, I am not impressed. It has a few limitations. First it is based on the Berkley C so the proposed ANSI extensions are not there. Items such as ( x += 5;) are not supported. The largest a program 'segment' can be is 64k. And the documentation is the worst I have ever seen apple put out. Here we have a toolbox interface and the documentation doesn't even talk about it, much less give an example. The toolbox reference manuals are some help but they only tell you what type of parameter the calls expect, not how to implement it - it is up to the programmer to figure this out. I'm going to use it only because that's all there is. But I'm damn dissappointed in Apple - again. Nick Silva AT&T Denver,CO. ============================================================================ Disclaimer: These opinions are my own and not those of the little green men that have been following me all day.
gwyn@BRL.ARPA (Doug Gwyn, VLD/VMB) (06/29/87)
You don't have to "implement" APW C interfaces to the ToolBox, since that's already been done for you in the C library. I can't fault APW C for not conforming to a standard that has yet to be published, although it would be reassuring if Apple would indicate an intent to conform in a timely manner.
sloan@pnet02.CTS.COM (Steve Smythe) (07/01/87)
Now Nick,
Remeber that everything you get from APDA is a "PRERELEASE" of the
actualy product. It specifically says that in the agreement you *SIGNED* to
be an APDA member... so take it easy. You might send your comments to some
APDA people so they can route it to the folks at Apple that designed the
package. Take heart! Borland's Turbo C wasn't really right the first release
either.....
_ /| ____________________
\'o.O' (___ / /__ | / /__
=(___)= _________) / /__ |/ /________
U
UUCP: {ihnp4!crash, hplabs!hp-sdd!crash}!gryphon!pnet02!sloan
INET: sloan@pnet02.CTS.COM
USmail: Steve Smythe, 727 San Simeon Ct, Concord CA 94518
AT&T: 415/685-1073
_ /| ____________________
\'o.O' (___ / /__ | / /__
=(___)= _________) / /__ |/ /________
U
UUCP: {ihnp4!crash, hplabs!hp-sdd!crash}!gryphon!pnet02!sloan
INET: sloan@pnet02.CTS.COM
USmail: Steve Smythe, 727 San Simeon Ct, Concord CA 94518
AT&T: 415/685-1073mdavis@pro-sol.UUCP (Morgan Davis) (07/01/87)
To Nick Silva et al: I agree about the APW C manual. Its pretty thin. And earlier versions of the Toolbox Reference from Addison-Wesley did not include an sample C calls for each tool call. A newer version *does* have C calls for every toolbox command, giving structure info, parameter lists, data types, etc. UUCP: [ ihnp4 cbosgd hplabs!hp-sdd sdcsvax nosc ] !crash!pnet01!pro-sol!mdavis ARPA: crash!pnet01!pro-sol!mdavis@nosc INET: mdavis@pro-sol.CTS.COM
ranger@ecsvax.UUCP (Rick N. Fincher) (07/01/87)
In article <4391@drutx.ATT.COM>, nick@drutx.ATT.COM (SilvaN) writes: > only because that's all there is. But I'm damn dissappointed in Apple - again. > In fairness to Apple it should be stated that this is a Beta version of APW C. Please correct me if I'm wrong. Rick Fincher ranger@ecsvax
MEPCOM-IM@STL-HOST1.ARPA (Karen Buck) (07/01/87)
not very encouraging is it. well there is an Alternative! I downloaded a copy ECP and ECP 16 off of GENIE and it has the shell , and I understand that ther will be a couple of real---non-Apple----compilers soon or already. Regards, Kevin Black -------
BHUBER@ECLA.USC.EDU (07/02/87)
I concur in your negative comments about APW C, although I hardly qualify as an expert, so my opinion doesn't count much. The documentation is an abomination. BTW, just received a flyer from Byte Works (creater of APW shell) and they will be releasing an ISO version Pascal compiler for $125 in mid-July. I don't know much about this product, but prior experience with other Byte Works products indicates it has a chance of being a winner. Bud
ranger@ecsvax.UUCP (Rick N. Fincher) (07/07/87)
In article <12314933218.19.MEPCOM-IM@STL-HOST1.ARPA>, MEPCOM-IM@STL-HOST1.ARPA (Karen Buck) writes: > not very encouraging is it. > well there is an Alternative! > I downloaded a copy ECP and ECP 16 off of GENIE and it has > the shell , and I understand that ther will be a couple > of real---non-Apple----compilers soon or already. > > Regards, > Kevin Black > ------- What is ECP? Tell us a little about it.
lwv@n8emr.UUCP (07/09/87)
ECP (extended/enhanced/external? I forget) Command Processor is a "shell" for either Prodos8 or Prodos16 (there is a ECP8 and ECP16). It is a shareware package by Don Elton from the Carolinas somewhere. The two shells together cost $40; either cost $30. ECP8 runs on ANY Apple II which runs ProDOS; obviously ECP16 only runs on GS compatible machines. The shell allows the installation of various types of external commands into a 'bin' like directory. The shareware package comes with about 2 dozen or so commands (type out a file, sort a prodos directory, talk to a modem, cat out a directory, give info about a directory's creation, etc.). It also comes with a help command and files which give you an idea of more of the scope of the paid-for system; there are probably a hundred or more commands in the whole package. The software is set up to restart when an external command calls the ProDos quit. With the publically available package you can copy files, move them, rename them, create directories, delete files or directories, squeeze and unsqueeze files, build ar like libraries OR Binary II libraries, etc. This provides quite a lot of capability. But the best is yet to come. The programs also provide a shell script capability; ie shell variables, looping, and other such exciting features. In other words, ECP provides MUCH of what APW provides, in a smaller package and at a lesser cost. The 'problem' is that it is NOT an APW replacement; there are some features (dont ask me - I am just repeating what I have been told) of APW that are NOT duplicated. One reason is time; Don is also supporting a number of other shareware projects (such as a shareware communications package called Talk is Cheap). Anyways, the bad news is that I don't have an address handy to give you for more info. Don has a CIS account and a Proline (I think that is the one) account that he commonly uses. If you have access to either service, try to track him down. The code is really too large to attempt to post thru the mail; even compressed the ECP8 package is I think over 100 Prodos blocks long; unpacked it is larger than a 5.25 inch disk (though it could probably be placed on two disks). -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 cbosgd!n8emr!lwv HAM/SWL BBS (HBBS) 614-457-4227.. 300/1200 bps
whitney@think.uucp (David Whitney) (07/10/87)
In article <173@n8emr.UUCP> lwv@n8emr.UUCP (Larry Virden) writes: > >ECP (extended/enhanced/external? I forget) Command Processor is a "shell" >for either Prodos8 or Prodos16 (there is a ECP8 and ECP16). It is a shareware >package by Don Elton from the Carolinas somewhere. The two shells together >cost $40; either cost $30. ECP8 runs on ANY Apple II which runs ProDOS; >obviously ECP16 only runs on GS compatible machines. > I am *more* than interested in this product. If and when ANYBODY gets a hold of an address or even the code (any sources?) either post it, or mail it to me. I will gladly pay the $40 to the author. I wonder, how "unixy" is it? I've grown accustomed to Unix, and I'd really like a shell on my GS which is very similar to it (for example, ls gives a directory - NOT cat or catalog). If I can't get a shell that is "unixy" enough, I'm desparate enough to write one myself. David Whitney 141 Rhinecliff St. (USENET courtesy of ..!ihnp4!think!whitney Arlington, MA 02174 Thinking Machines Corp., whitney@think.com (617) 643-3155 Cambridge, MA) My opinions - no one else's -- SO THERE!
ranger@ecsvax.UUCP (Rick N. Fincher) (07/11/87)
In article <6312@think.UUCP>, whitney@think.uucp (David Whitney) writes: > In article <173@n8emr.UUCP> lwv@n8emr.UUCP (Larry Virden) writes: > > > >ECP (extended/enhanced/external? I forget) Command Processor is a "shell" > >for either Prodos8 or Prodos16 (there is a ECP8 and ECP16). It is a shareware > >package by Don Elton from the Carolinas somewhere. The two shells together > >cost $40; either cost $30. ECP8 runs on ANY Apple II which runs ProDOS; > >obviously ECP16 only runs on GS compatible machines. > > > > I am *more* than interested in this product. If and when ANYBODY gets a hold > of an address or even the code (any sources?) either post it, or mail it to > me. I will gladly pay the $40 to the author. I wonder, how "unixy" is it? > I've grown accustomed to Unix, and I'd really like a shell on my GS which > is very similar to it (for example, ls gives a directory - NOT cat or catalog). > If I can't get a shell that is "unixy" enough, I'm desparate enough to write > one myself. > The Address is: Donald Elton 2916-A Chatsworth Road Columbia, SC 29223 He has both ECP and the "Talk Is Cheap" shareware programs, maybe more. If it's a Unix-like shell you want, try Aztec C. It has a Unix-like shell that runs under prodos. It has ls, rm, cp, cd, mv, mkdir, pr, pwd, cat, diff, grep, cmp among others and an exec file language with looping. Of course, you also get C. It would be a little expensive to buy just for the shell, though. See Byte magazine for Manx's ads for their Aztec C compiler if you are interested. You may want to write your own just for fun though :-). Rick Fincher ranger@ecsvax "DISCLAIMERS! We don't need no stinking disclaimers!" Carolina System Software
dr@ski.UUCP (David Robins) (07/16/87)
Another UNIX-like shell is Kyan KIX, which I believe runs under ProDOS.
It replaces Apple ProDOS commands with UNIX-like commands, such as ls,
rm, cd, etc.
It has nothing to do with C, unlike the Aztec shell, which is
specifically for its own C programming environment.
KIX is advertised frequently, it is not expensive, ie. in the $30 to $50
range. IT was reviewed not too long ago in one of the Apple
magazines, but I don't recall the reference.
--
====================================================================
David Robins, M.D.
Smith-Kettlewell Eye Research Foundation
(previously known as: Smith-Kettlewell Institute of Visual Sciences)
2232 Webster St; San Francisco CA 94115
415/561-1705 (voice)
{ihnp4,qantel,dual}!ptsfa!ski!dr
The opinions expressed herein do not reflect the opinion of the Institute!NU092254@NDSUVM1.BITNET (Brian Dall) (07/19/87)
Kix was reviewed in NIBBLE, vol. 8 no. 4 (April 1987).
I'm not sure how you would get back issues. I could summerize via mail
if you are interested.
take care,
-Bri
________________________________________________________________________
Brian Dall | |"It is dangerous to tell
PO Box 5112 | NU092254@NDSUVM1.BITNET | the people that laws are
NDSU Station | | not just. . . ."
Fargo, ND 58105 | | -Blaise Pascal
========================================================================
standard 'no affiliation' disclaimer
BHUBER@ECLA.USC.EDU (12/28/87)
ADPA membership (for U.S. people) is $20.00 per year. Address:
Apple Programmer's and Developer's Association
290 SW 43rd Street
Renton, WA 98055
206-251-6548
There has been (to my knowledge) only one release of APW C and it is still
called a beta release. APW C, version 1.0B7 is $75.00 from APDA. You must
have APW shell (or Byte Works equivalent) to run APW C.mdavis@pro-sol.cts.COM (Morgan Davis) (05/13/88)
Scott Lindsey (of StyleWare) writes: > I don't view APW C as a viable development tool [because it lacks] > assembly-level debugging. Are you talking about data flow analysis and a source-based symbolic debugger, or just the ability to pop into DEBUG and trace through your code? If the latter, you can EASILY use DEBUG. While everyone is bitching and moaning about having to trace through the stuff from START that gets linked in, the code beyond that is real assembler and can be traced just like any ordinary assembly program. Serious developers shouldn't even use START.ROOT, as any major IIGS product does not require the extra baggage that START provides. Jonathan Arnold (Infocom) was first to realize this and wrote an alternate START program. Here's all it does: KEEP "START" ; ; STRIPPED START for APW C users ; Jonathan Arnold, Round the Bend Software ; ; Use/change/distribute to your hearts content, but please don't screw ; it up and then use my name. Fair enough? ; CASE ON ; case sensitive _start START main ; start in "main" load seg ; ; get the data bank of ~globals ; * This commented portion is J. Arnold's original code * * sep #$20 ; just using 8 bits * LONGA OFF ; ditto * lda #(_toolErr|-16) ; get bank addr of myID * pha ; get ready to goto bank * plb ; only way to open bank * rep #$20 ; back to 16 bits * LONGA ON ; ditto * jsl main ; and away we go * * I changed it to the following (saves 2 whopping bytes): lda #(_toolErr|-16) ; get bank addr of _toolErr xba pha ; get ready to goto bank plb ; only way to open bank plb jml main ; and away we go * I also use a JML instead of JSL to call main in case main does not * exit via ProDOS 16's QUIT function. (Using a JSL means that if main * returns via RTL, the PC goes heading out into the weeds.) Most EXE * files under APW or ECP16 can return via RTL without problems, so even * leaving out the QUIT call is normally safe. DO NOT leave it out if * your program is an S16 filetype!!! -- Morgan Davis, 1/21/88 END ~globals DATA ~globals _toolErr ENTRY DS 2 ; where to put tool problems END What follows the "jml main" is the *real* code that your program uses (and maybe a few utility routines linked in from the C library -- i.e. math stuff, bit shifting, string routines, etc.). Using this alternate START also cuts back the size of your C programs so that they can be even more compact than equivalent programs written in TML Pascal (as an example). I've done a lot of disassembling of the code produced by the APW C compiler and it has surprised me a few times by how efficient some processes are carried out in 65816. The hardest thing to get used to is just seeing how the arguments are passed between function calls. Other than that, it is really quite compact. (I wrote a C program, File Fixer, which takes up 21 blocks total. With the regular START, it takes up over 65 blocks after compacting. An equivalent program in TML Pascal would take up about 29 blocks.). After all, most IIGS programs boil down to a lot of toolbox calls. --Morgan Davis UUCP: crash!pnet01!pro-sol!mdavis ProLine: mdavis@pro-sol ARPANet: crash!pnet01!pro-sol!mdavis@nosc.mil InterNet: mdavis@pro-sol.cts.com
wombat@nuchat.UUCP (Scott Lindsey) (05/14/88)
[Sorry if this is a duplicate posting] From article <8805121956.AA21868@crash.cts.com>, by mdavis@pro-sol.cts.COM.UUCP: > Scott Lindsey (of StyleWare) writes: >> I don't view APW C as a viable development tool [because it lacks] >> assembly-level debugging. > That's not what I said. I said I don't view it as a viable development tool because of the _necessity_ of assembly level debugging. (I also said that this was only one reason). > Are you talking about data flow analysis and a source-based symbolic debugger, > or just the ability to pop into DEBUG and trace through your code? If the > latter, you can EASILY use DEBUG. I was basically referring to the former. On the GS I use assembly (that's what was there first) for the most part. My C background is under BSD unix where I used dbx, a symbolic debugger. When I use debug with my assembly code, no problem. When I use it with C generated code, it's a guessing game figuring out how the compiler was written. Little library routines to do bit shifting, integer comparisons done differently than I would, etc... are things which, while necessary, make life hard. Since you seem to have done some work with APW C, I'll ask your opinion. First, have you written anything big (multi-bank) using APW C? Did it work properly? I ran into problems when I had to put different segments into different banks. I have to assume that it's probably library routines with bank dependencies... but I don't have the time to figure out which library routines are at fault. -- Scott Lindsey uunet!nuchat!wombat | These are _my_ opinions. StyleWare, Inc. | 5250 Gulfton 2E | It was a cold night for alligators Houston, TX 77081 | ... a cold night for dogs.
dougm@lakesys.UUCP (Doug McIntyre) (12/20/88)
Should I even report bugs about APW C (or any APW products) in? The way the apda log reads, it says this is it for them.. I've got about 3 pages of bugs and sugestions. Mainly dealing with upperlimits of APW, and the various weird things that happen when you reach them, such as your filter program filters out too much, and so forth.. I'm beginning to really hate APW now.. Before it was just kind of a dull pain.. But this is really too much.. -- ------------------------------------------------------------------------------ UUCP: uunet!umix!lakesys!dougm Compuserve: 70611,2215 INET: dougm@lakesys.UUCP APLE: DougMac ------------------------------------------------------------------------------
hb@kuling.UUCP (Henrik B}kman) (10/10/89)
Is APW C good? Does it have many bugs (I HATE compilers with bugs!) Does the new ORCA Shell come with some sort of resource editor? And do you use the linker to include the resources in your programs? How much does the newest version of the ORCA Shell with the assembler cost? Thanx, Erl
lvirden@pro-tcc.UUCP (Larry Virden) (10/14/89)
Network Comment: to #964 by mcsun!sunic!bmc!kuling!hb@uunet.uu.net
I have seen recent notes concerning the latest update of APW C (someone
had gotten the 5.0 based upgrade from what I understand) and there was some
concern when pieces of structures were missing, in the wrong header files,
had wrong names, and I even think I remember them saying something about
getting syntax errors!
--
Larry W. Virden ProLine: pro-tcc!lvirden
674 Falls Place Work: lvirden@cas.bitnet
Reynoldsburg, OH 43068-1614 Aline: LVIRDEN
CIS: 75046,606