Path: utzoo!attcan!uunet!jarthur!usc!ucsd!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: Orca/C and Orca Environment
Message-ID: <12988@smoke.BRL.MIL>
Date: 25 May 90 04:04:21 GMT
References: <12450.netnews.info-apple@pro-novapple> <IaL1GL200VR0I3dUc=@andrew.cmu.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 55

In article <IaL1GL200VR0I3dUc=@andrew.cmu.edu> jm7e+@andrew.cmu.edu (Jeremy G. Mereness) writes:
>> How about NCSA Telnet -- a lot of us are looking for something like that on
>> the GS.
>Yes... could this new compiler handle tasks such as this? Porting a
>program from say, a Mac, IBM, or Unix environment? 

There is much more involved in porting C applications across different
operating system environments than any compiler could reasonably be
expected to take care of.  In fact, anybody who tries to bring up NCSA
Telnet on the GS should soon discover that it is a nontrivial task and
that the worst problems are not ones that can be addressed by the
C software generation system.

>The complaints about the current ORCA/C have been so loud, 64K limit,
>bad editor, and so forth, that I have been holding off for a long time.

Release 1.0 of ORCA/C is difficult to use simply due to bugs, for example
generating incorrect code for static objects.  However, these have been
fixed in the Beta test versions of Release 1.1, which is very solid at
this point.

ORCA/C actually supports two "memory models" and comes with libraries
for both.  The "small model" has 64K data constraints but the "large
model" lifts these at the cost of somewhat slower access to the objects
and slightly larger code.  No single function can contain more than 64K
of code, but there is no reason for anybody to write code that exceeds
that limit.

The desktop text editor works quite well in the current released version,
although on RARE occasion I am still able to get it confused (in which
case quitting and restarting usually fixes things).  It is certainly good
enough for routine software development, and is tied into the compiler's
error detection so that the cursor is automatically placed on the line
where the error was detected.  This is quite handy.

>The first thing I would do with a C compiler for the GS would be to port
>software from other platforms; I wouldn't be interested in anything that
>would have unusual difficulties accomplishing this. 

The only real problem used to be the excessive bugginess, but as of
Release 1.1 (which will be sent to registered owners of 1.0 as soon as
it is available, and can be obtained in Beta test form now just for the
asking on AO), it should be eminently usable.  However, don't expect the
C library to provide fork() or AmigaDOS system calls.  Nonportable stuff
like that you should always expect to have to deal with when porting C
applications across platforms.  Note also that the Apple IIGS desktop
tools don't have the same interface as the analogous Macintosh tools,
although the concepts and usage are similar.

>Are you saying that ORCA/C 1.1 _will_ fit the bill? Nearly as reliable
>as /bin/cc in Unix? 

ORCA/C 1.1 is the only viable choice I know of for a C compiler on the
Apple IIGS.  APW C is usable but rather out of date.  Aztec C works but
only for the 8-bit environment, which is too limiting for the IIGS.