SAGE@LL.ARPA (01/11/89)
There is one comment about gaining access to Z-System facilities with programs written in high level languages that I neglected to make earlier. There is, in a weak sense, an operating system call that returns the ENV address. The ZCPR command processor since version 3.3 has placed the environment address in the HL register on entry to a program. If the high level language allows the user to gain control before some initialization package loses the information in HL, then this can be used (but, as always, should be validated before it is trusted). This is essentially a modification of Bridger's patch suggestion or the suggestion of recoding C.CCC. It is much easier just to save the contents of HL than it is to create the whole Z header as Bridger described. Such a program, however, will fail with versions of ZCPR before 3.3. BackGrounder ii has supported this facility from the beginning, however, and will work fine. Having a real DOS call is a very interesting idea. Perhaps the DOS version function call could return the ENV address as well. The problem is that the new DOSs may already be absolutely full, with no spare bytes for this. But it is certainly a suggestion worth passing along to the authors. Also, if you are using one of the public-domain DOSs (Z80DOS, P2DOS, NOVADOS), then you can try putting it in yourself. Another possibility is to load an RSX that would provide this extended service. The roughly 2K memory cost might, however, be too much to pay. It might be an interesting and easy way to experiment, however. -- Jay
dgee@cup.portal.com (David O Goodman) (01/13/89)
In article <SAGE.01053864@LL.ARPA> SAGE@LL.ARPA writes: > There is, in a weak sense, an operating system call that returns the ENV > address. The ZCPR command processor since version 3.3 has placed the > environment address in the HL register on entry to a program. If the high > level language allows the user to gain control before some initialization > package loses the information in HL, then this can be used (but, as always, > should be validated before it is trusted). ... The problem, or course, is that the IF ("if the high level language..."), is a very big IF indeed! It seems to me that most HLLs running under cp/m must, of necessity, have the entry to their initialization routines at 100h, where they will execute before any routine the programmer provides. > Having a real DOS call is a very interesting idea. Perhaps the DOS > version function call could return the ENV address as well. The problem is > that the new DOSs may already be absolutely full, with no spare bytes for > this. But it is certainly a suggestion worth passing along to the authors. The suggestion was a system call which would return the ENV address. It seems to me that this would provide a standardized way for any program, ASM or HLL, to obtain the information. Presumably, the present system would also have to be maintained for backward compatibility. But the present system is really, with all due respect to Jay, a kludge, albeit an ingenious one. When ZCPR 3.0 was written, the Cp/m world was stuck with the Digital Research bdos, so another way had to found to transfer the ENV address to a transient program. Z3INS was the answer; and under ZCPR 3.3/3.4 Jay ingeniously converted the original installation system to an auto-install system. Now, however, we have alternatives to the Digital Research bdos, and one or the other of these alternatives are probably going to be used on most up to date systems. We expect to be able use calls such as #27 (return ALLOC address), #31 (return DPB address); what is conceptually different about call #nn (return ENV address)? -- Dave Goodman dgee@cup.portal.com ...sun!portal!cup.portal.com!dgee