iphwk%MTSUNIX1.BITNET@cunyvm.cuny.edu (Bill Kinnersley) (08/11/88)
[In "Re: ARP commands--How do you make them so small?",
Leo 'Bols Ewhac' Schwab said:]
>
> Your dilligent searching out and mapping of AmigaDOS and its BCPL
> realm is to be commended. However, CATS types have said in the past that
> they are opposed to documenting the BCPL entry poiints, since that will make
> it all the more difficult for them to go in and re-write DOS in C and
> assembly.
>
> Therefore, I would suspect that using the information to any great
> extent beyond intellectual curiosity is not a good idea. It's not
> supported, and Commodore reserves the right to break anything that's not
> supported.
>
I would never intentionally do anything to perpetuate the use of BCPL,
or make its replacement more difficult.
Let me explain. Back when the idea of replacing the CLI commands got
started, there were C programs appearing which replaced STATUS, INFO,
etc. Heck those are easy, I thought. I'll write a replacement for
NEWCLI and really learn something. Well what I quickly realized was
that I didn't have the faintest idea how to start. All the CLI data
structures were there before me in the AmigaDOS manual, but the comments
on how they could be properly used were totally cryptic.
To quote from one of the Elder Gods: (date: Nov 2, 1985)
> "It's been said that the Amiga is a hacker's machine. I surely wouldn't
> dispute that -- that's why we're going public with all (and I mean ALL)
> of the technical info so early. Hacking, of course, starts with total
> control."
As far as the data structures go, this is 100 percent correct. They
didn't mislead us. AmigaDOS does indeed use exactly what's published
in the Technical Reference Manual. No secrets there. But the secrets
lie in the function library.
Only some of the function calls have been brought out in public in
the dos.library for use by C programs. (And, I might add, if that had
been done right, you'd have never had to see a BPTR.) My claim is that
the functions should have been published in the Tech Ref Manual alongside
the structures. They go hand in hand, and how can you support one without
the supporting the other.
I think that this BCPL library is not about to disappear. As long as
there is any BCPL left in the system, the library will have to be there.
As long as I'm booting with the not-so-fast File System I know it's there.
And for compatibility it will *have* to be there in essentially unchanged
form, even though it's not officially supported. It will necessarily
be the last thing to go. When it does go, we will be incompatible with
previous OS releases. This is the distant dream called 2.0. Something
for my grandchildren to worry about along with the ozone layer.
Again my point in delving into the AmigaDOS innards was not because I
just looove BCPL. It was partly because, as a hacker, I abhor a black box.
But basically I just wanted to do a NEWCLI in C.
What I discovered was that even after I knew how to do it, I STILL could
not do it. There are calls in the BCPL library (particularly those
involved with Process creation) which are essential for this. They could
easily have been brought out into dos.library, but for some reason were not.
So the choice is either to call the BCPL library from C or else write
lengthy assembler that duplicates the missing functions. Assembler, in
my mind, is not that much preferable to BCPL.
What I hope I've done is to outline a safe and sanitary way of using
these missing calls from a program which is written in C. That's all.
(Note, by the way, that the example I posted did not go as far as it
could have. It used both the BCPL run-time library and the C run-time
library, and therefore was a how-to-do-it-in-principle thing, rather
than an a minimum size thing. Put it in _main() rather than main() and
eliminate the printf's and so on, and you'd get a really small C
executable.)
--
Bill Kinnersley
Physics Department BITNET: iphwk@mtsunix1
Montana State University INTERNET: iphwk%mtsunix1.bitnet@cunyvm.cuny.edu
Bozeman, MT 59717 CSNET: iphwk%mtsunix1.bitnet@relay.cs.net
(406)994-3614 UUCP: ...psuvax1!mtsunix1.bitnet!iphwk
"This message was packed as full as practicable by modern electronic
equipment. Some settling of contents may have occurred during transmission."