Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!gatech!udel!mmdf
From: iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley)
Newsgroups: comp.sys.amiga
Subject: Re: Bug in 1.3 ChangeTaskPri
Message-ID: <5838@louie.udel.EDU>
Date: 6 Dec 88 15:57:36 GMT
Sender: mmdf@udel.EDU
Lines: 55

[In "Re: Bug in 1.3 ChangeTaskPri", Peter da Silva said:]
:
: In article <10435@rwan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes:
: > iphwk%MTSUNIX1.BITNET@cunyvl.cuny.edu (Bill Kinnersley) wrote:
: > >INITIAL ENVIRONMENT [at process launch]:
:
: > Thanks, but I want *CBM* to document it, so wd can depend on it.
:
: I'd rather CBM disavowed it...

I'd be happy if they did either one!  The situation has remained unchanged
for 3 years now, and CBM really needs to make up their minds one of these
days what they are going to do about this.  I can't guess what changes are
coming or when, but each time a new OS release comes out and the BCPL is
still there, that's another missed opportunity.

The way I see it, Peter, they write the OS and we write the applications,
and on the bottom line it makes little difference to me whether they choose
to do the OS in C, or BCPL, or Modula 2, just so they document the interface.

: most of that stuff seems like whatever the BCPL runtime would have
: in those registers at that point.

At the present time, a shell does need to allow for the possibility of
applications written in BCPL.  If the shell wants to support these existing
programs, it HAS to pass all of this stuff in the registers at program
launch.  The official CBM line that only D0 and A1 need to be passed just
doesn't wash.

It seems to me that a shell would want to do the following:

   Look in DosLibrary->dl_GV.  This is the BCPL Global Vector, and if it
   is nonzero, that should indicate that BCPL is still in my machine.
   If it is zero (glory be), that should mean that BCPL has disappeared.
   (Is this too much to expect, Andy?)
   If dl_GV is nonzero, pass the BCPL environment to the application.
   All the "secret" fields you need are waiting right there for you
   in DosLIbrary->dl_A2, dl_A5 and dl_A6.  This will keep both BCPL and
   C programs happy, as C programs will ignore the extra stuff anyway.

: There's enough BCPL junk in the O/S as it is... why add more stuff that
: CBM will have to keep emulating until the end of time?
:
: Equally, the more you know about BCPL, the more your code is likely to break
: on that eagerly awaited day when 2.0 comes out.

My Workbench disk is full of BCPL programs, and I'm not the one who wrote
them.  I'm not writing more BCPL, just trying to understand what's
out there already, enough to support it in a compatible fashion.  In the
present situation, a correctly functioning shell needs to know
a minimum of BCPL.

I can't help it, Ma, I didn't wanta learn about BCPL!  They made me do it!

--