Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site 3comvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!pyramid!hplabs!oliveb!3comvax!mykes
From: mykes@3comvax.UUCP (Mike Schwartz)
Newsgroups: net.micro.amiga
Subject: Re: Processes and return values
Message-ID: <471@3comvax.UUCP>
Date: Mon, 14-Apr-86 14:43:03 EST
Article-I.D.: 3comvax.471
Posted: Mon Apr 14 14:43:03 1986
Date-Received: Wed, 16-Apr-86 05:08:43 EST
References: <11701@watnot.UUCP> <974@amiga.amiga.UUCP> <979@amiga.amiga.UUCP>
Reply-To: mykes@3comvax.UUCP (Mike Schwartz)
Distribution: net
Organization: 3Com Corp; Mountain View, CA
Lines: 93

In article <979@amiga.amiga.UUCP> robp@dudley.UUCP (Robert A. Peck) writes:
>Responding further to Matt and Rico .... AmigaDOS has been flamed for
>the way it does certain things and people have, along the way, either
>found or been given the tools that are needed to perform various
>operations in a more suitable ( Un*x-like?) manner.  People who write
>things like CLI's most probably will be building in various command
>ability rather than asking the DOS to load the command such as type,
>copy, and so on.  I venture to say that there will be very (very very very???)
>few applications released based purely on BCPL and developed with the
>full background of knowing AmigaDOS-related TRIPOS process internals,
>since the experts therein are very few and far between.  So why not 
>concentrate on applications for and in the languages with which we are
>all most familiar.

I understand Rob's frustration due to the regular flaming of the CLI that
seems to be happening here.  However, I understand the frustration that led
to all the flaming in the first place.  To some of us, the CLI is the most
important piece of software on the machine.  To others, workbench is more
important.  I like to use both, and understand that the Amiga needs workbench
applications as much as it does CLI applications.

I am a developer, and use my Amiga to edit/compile/debug.  Therefore, to
me, the CLI interface is extremely important, and we all know the pros/cons
about the current CLI.  Rob, I think that there are several people working
on CLI replacements because there is a tremendous need perceived by most
people who use the current CLI - pure and simple.  But CLI is only one
of the real needs.  Serious debugging and development tools all use AmigaDOS
(as opposed to custom disk drivers using TrackDisk) so that data can be shared.
It is nice to be able to write programs like gi, which takes an IFF file and
generates c-source for images.

When you consider that there are countless MS-DOS internals hackers and
Unix internals hackers, you gotta realize that there must be a need to
deal with the internals of an OS.  Making the OS do tricks is not only
a challenge to guys like Matt, but NECESSARY for the future success of the
machine.  If you look at the Shell that Matt did (or other shells I have
seen), there is no doubt that a great deal of improvement has been made
so early in the game (for the CLI).

If you remember way back to one of Matt's earlier postings, he flamed the
Amiga OS (and Rom kernel).  Then he actually wrote a program (the Shell) and
changed his tune quite a bit (he later wrote that there were only a few
things wrong with the Amiga software).  His only real gripe was that there
weren't enough higher-level support packages to do the things he wanted to
do.  

AmigaDos (TRIPOS) shows so much potential on the Amiga, yet it is near
impossible for severl (vocal) developers to allow that potential to come
through.  And the CLI has all the problems that have been flamed about,
especially if you have to use it all the time.  For example, just a
simple way to edit the last command typed would be greatly appreciated.
Why shouldn't a CLI for the Amiga have it's own pull down menus, work
in 640x400, talk, and do Unix kinds of things, if that is what the 
individual user wants?

I use 640x400 for text whenever possible, because I can choose colors that
hardly flicker and I like the extra 20+ lines I can read on the screen.  I
use 640x400 in my own terminal program that I use to talk to unix, and
unix never looked better to me than it does with 48 lines on the 
screen.

The frustrating thing for a developer is that you can tell that somewhere
BURIED IN THE INTERNALS of AmigaDos, some routine calls OpenWindow() to
open a raw: window or con: window if you open("raw:n/n/n/n/title...),
and that ANY CLI COMMAND with stdout redirected to the resulting
FileHandle will go to that window.  I know for a fact that the console.device
works wonderfully with a 640x400 screen, so there is no reason why any of the
CLI commands would not work in 640x400.  I wish that there were some way
to open a window via open("raw:...), and somehow substitute a window of
my choice (my own NewWindow structure instead of the default one) for the
one that CLI uses (and thus any application run from that CLI).

This is just one example of why developers might want to get into the
bowels of TRIPOS, and to me the above capability would please me to no end.
I am sure that there are many such examples of internal kinds of things that
people want to do.  Another example is I want to have a CLI window 
in front of my own Custom Screen.  Sorry Charlie.

I hope that this hasn't sounded too critical, because it wasn't meant to
be.  I understand what a mess TRIPOS really is, because I have studied
all of the manuals (Tech Reference, Developer's Manual, User's guide)
many times over (trying to figure out how to do some of the above).  I 
realize that somewhere in the middle levels of the code, TRIPOS had to
be hacked at to get it to work on top of the ROM Kernel stuff.  And I don't
want to see BCPL sources (I don't got no stinkin' BCPL compiler).

The folks at C-A have been extremely helpful to all of us on the net, and
have provided a tremendous amount of support, in terms of writing or giving
sources to us, writing higher level support routines for things that we
need to do a lot (CreateTask, CreatePort, etc.), documentation, and PERSONAL
attention.  Kudos to them for all the help.  On the other hand, they
shouldn't discourage people from trying to become TRIPOS internals experts
unless they plan to switch over to a new OS or something.