Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty From: scotty@l5comp.UUCP Newsgroups: comp.sys.amiga Subject: Re: BCPL/AmigaDOS Message-ID: <147@l5comp.UUCP> Date: Sun, 24-May-87 18:38:42 EDT Article-I.D.: l5comp.147 Posted: Sun May 24 18:38:42 1987 Date-Received: Thu, 28-May-87 06:03:07 EDT References: <461@inria.UUCP> <1920@cbmvax.cbmvax.cbm.UUCP> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA Lines: 60 Summary: But what about US?!? In article <1920@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >it in any meaningful way. One of our goals is to change >the environment into a C style world, and continue the task of >'less BCPL' in the Amiga OS. > >It would be *really* bad if suddenly a lot of programs started counting >on the BCPL world being there. > >Sorry 'bout that folks... > > 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! 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. Suggesting that I go buy the Manx C package so I can use their non-100% compatible assembler wouldn't cut it for example. And that PD assembler from back east doesn't cut it either. 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... I'm all for ridding the world of BCPL, but it seems to late to do so now. 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. Granted BCPL code has more problems that this (BIG understatement :) but these other problems are isolated inside the BCPL code itself. 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) 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? 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 and the non-BS version of how to do things, or REQUIRE that the users of the software get the non-BS OS. And as soon as rumors start floating that this is indeed going to happen we'll see the same thing happen that happened with 1.2. People will stop releasing software! They'll have to because who wants to re-release their software to work with the new version? Why not just wait till it shows up then release? We saw it before, we'll see it again. Heck we saw it with 1.1 too! Almost nobody released software for 1.0. But if we're going to rid the Amiga of BCPL how about we bag some other stuff too? :) I've got a shopping list a foot long of architectural things it would be nice to change but can't because they'd bust software. And right now the last thing we want to do is bust what little software we have. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)