Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!philabs!steinmetz!jesup
From: jesup@steinmetz.steinmetz.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: BCPL/AmigaDOS
Message-ID: <6083@steinmetz.steinmetz.UUCP>
Date: Fri, 29-May-87 16:46:43 EDT
Article-I.D.: steinmet.6083
Posted: Fri May 29 16:46:43 1987
Date-Received: Sun, 31-May-87 12:42:30 EDT
References: <461@inria.UUCP> <1920@cbmvax.cbmvax.cbm.UUCP> <147@l5comp.UUCP>
Reply-To: jesup@kbsvax.steinmetz.UUCP (Randell Jesup)
Organization: General Electric CRD, Schenectady, NY
Lines: 75

In article <147@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes:
>In article <1920@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes:
>>It would be *really* bad if suddenly a lot of programs started counting
>>on the BCPL world being there.
>>
>>		andy finkel
>But what about all that BCPL code we're already using?!? I don't want my MCC
>shell and assembler to go bye bye!

	Then get a real shell :-) [no offense intended]  Really, if the
MCC people used the undocumented BCPL interfaces, because they happened to 
know exactly what they did, they deserve whatever they get.  They have an 
unfair advantage over the rest of us to whom those internals are taboo 
[even if you know how they work, you can't use them because they aren't
 guarenteed to continue to work the way they appear to now. ]
>
>C-A has ALREADY shown me it has almost ZERO interest in upgrading anything
>except the operating system (and at times I barely beleive that ;) If you
>guys shoot the BCPL links fine, but I better have some way of getting
>inexpensive replacements THAT WORK THE SAME as the tools I already have.

	If you want an EXACT replacement, talk to MCC.  If you want something
better, it's coming (and it would be better yet if it wasn't for BCPL).

>And what about my new ram-handler? You guys going to bust it too? :) Fine,
>but I better be able to relabel with the new one...

	If you wrote it using the BCPL interface, you may lose.  If you did
it in the supported way (non-BCPL, GlobVec = 1 in the Mountlist) it should
work fine.

>BCPL isn't
>the real problem, its those damn BPTRs! And yall can't change them without
>busting nearly every program written for the Amiga.

	You're right.  But the BPTRS hurt you worse inside the DOS than
outside (performance wise).

>Hmmm, except for that idiot "grab 1500 bytes of
>stack right off the top" in the dog.library interface. But BCPL doesn't use
>that anyway that I've ever seen. (BCPL seems to have a hot line into the dog)

	It does use up to that amount, from the bottom of the stack up.
Simple calls use only a little, but some can use quite a bit (this is the
upside-down stack referenced off of A1).

>So that means that's just a bad dream that should be made to go away. Hmm but
>that 1500 bytes is needed so you can call the BCPL isn't it?

	Right.

>In any case, it would seem to do the world more good to leave the BCPL hooks
>alone and just cleanup the dog's act about using the disk.devices. After all,
>everyone has already dealt with the BCPL BS in their code. If yall remove the
>BS WE will either have to write our code so that it has the BS version andthe
>non-BS version of how to do things, or REQUIRE that the users of the software
>get the non-BS OS.

	NO!  You're right that the filing system needs improvement, but there
are MANY other areas that are brain-dead, only available via the undocumented
BCPL calls or just plain missing.

>And right now the last thing we want to do is bust what little software we
>have.

	Very little depends on the internal BCPL calls now anyway.  The only
thing really required is for the structures to remain the same (complete with
BPTRs).  At best you can provide alternitive calls for those that use BPTRS,
but you must keep the originals around.

>Scott Turner

	Randell Jesup
	jesup@steinmetz.uucp
	jesup@ge-crd.arpa