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! --