david@bdt.UUCP (David Beckemeyer) (02/08/90)
[ This was originally intended to go out as mail to John Stanley, but that bounces. I think this may be interested to the net anyway. ] John Stanley said: > I saw RTX come across the net, but due to a hardware problem, I > missed most of the posting and am probably going to have to grab it > off of GEnie if/when I do have a machine with enough memory back up > and running (now using a badly overloaded/under-RAM'ed 1040 and my > primary machine (4+meg 1040) is still in the shop..<sigh>).. To use the basic RTX kernel, you really don't need that much memory. It's designed to be lean and mean. The kernel itself uses only about 32K. You can proably run the whole thing in less than 100K. Re Fforce etc.: I don't think you're going to need the Pexec+HBlank trick when RTX is running. Can you explain a little bit more why it is needed under RTX? I don't think there's any way to guarantee this is going to work in a multitasking system where the process doing the Pexec could be suspended at any time during the start of the child. What's more the child may be started concurently. There is a "p_create()" RTX hook that could be used to guarantee that your "extra startup" stuff happened in the correct context. I'll explain a little bit about how Fforce works in RTX. There isn't any "stack". RTX follows the GEMDOS / PC-DOS definition of handles. Each process has a set of "standard handles". These may be redirected. In RTX there is an internal table of "active" handles. This table contains information about all active handles, both "standard handles" and "non-standard handles". Each handle is "owned" by a certain process. Standard handles are really just a per-process table of six entries in the "active" table (a double indirect). When Fforce is used, the entry in the "active" table for the non-standard handle is copied to the entry for the standard handle. If a process closes one of its standard handles, it basically has no effect. The handle actually remains active and open; the Fclose() call returns with an EIHNDL error. When the process terminates, all its "active" handles are "freed" and files and pipes opened in this process context are closed. Files opened by the parent, and redirected are not closed. RTX also "knows" how each handle is opened, in terms of what it's talking to and it deals with the different handles (files, pipes, and ttys) differently. Any owner of a handle can determine what the handle is talking to via the Fcntrl() and Ftype() calls. File operations attempted on handles not owned by the correct process result in EIHNDL errors. Neither GEMDOS nor PC-DOS are defined to "stack" Fforce. It's not the way that redirection is done under MS-DOS type systems. Correctly written GEMDOS / PC-DOS programs don't expect Fforce to "stack"; Fdup() is the stacking mechanism. Programs that rely on other methods are out-of-spec and therefore are in error. If they don't work right, tough. They have a bug unless they use the supported method of redirection. Closing a standarnd handle isn't fatal in RTX though -- it's basically a no-op. Many times with RTX there are cleaner ways to solve a problem using documented system services, such as Fcntrl(), Ftype() etc. As for detecting the presense of RTX, the easiest and "cleanest" way is to just try to use one of the RTX GEMDOS extension traps, such as Ftype() on handle zero (STDIN). Ftype is GEMDOS opcode 0x101. In standard GEMDOS, this always will return EINVFN (-32, invalid function). In RTX this will return some number between zero and seventeen. Using the C bindings, you could just use: if (gemdos(0x101, 0) == EINVFN) /* no, RTX isn't here */ else /* yes, RTX is here */ If you wanted to be more sure, you could validate the return from the gemdos call more, but the above has always worked and probably always will. No other GEMDOS stealers have used opcode 0x101 yet. The other thing that is much uglier is that yoou could look at the value at the RTX vector for trap #4 (at $94) and see if it has the high byte set or not. If it is set, then RTX isn't loaded at all. If it is set, then RTX may be loaded, but you can't be sure if it's active or not until you try something like the Ftype(0) check above. The nice thing about the Ftype(0) check is that it's a NO-OP in RTX and also regular GEMDOS. It doesn't hurt anything. It's fast and it's reliable. TOS always safely returns EINVFN when given an out-of-range function number. > --- > John Stanley <john@dynasoft.UUCP> > Software Consultant / Dynasoft Systems > -- David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have Beckemeyer Development Tools | a breath mint." P.O. Box 21575, Oakland, CA 94620 | Bart - "The Simpsons" UUCP: {uunet,ucbvax}!unisoft!bdt!david | -- David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have Beckemeyer Development Tools | a breath mint." P.O. Box 21575, Oakland, CA 94620 | Bart - "The Simpsons" UUCP: {uunet,ucbvax}!unisoft!bdt!david |