Date: Mon, 27 Nov 1995 14:04:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: grog@lemis.de Cc: msmith@atrad.adelaide.edu.au, hackers@FreeBSD.org Subject: Re: Where is the documentation for ibcs2? Message-ID: <199511272104.OAA19524@phaeton.artisoft.com> In-Reply-To: <199511271616.RAA05014@allegro.lemis.de> from "Greg Lehey" at Nov 27, 95 05:16:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > In context, an executable. > > What kind of executable? A shell script, a FreeBSD binary executable, > a Linux executable, a BSD/OS executable, a NetBSD executable, an ibcs2 > COFF executable, or something else? That's a serious question. If > you don't know what it is, you can't (in a general case) tell how to > execute it. Actually, this is false. It is the problem of /sys/kern/kern_exec.c to figure this out on your behalf. It will either have an "image activator" (I prefer the term "execution class", since shell scripts are images, but whatever), or it won't. If the "magic number" doesn't match one of the intrinsic (compiled in) or extrinsic (loaded or scripted) binary types, you'll get a "Command not found" or an "Exec format error", depending on the permissions and your shell's handling of an ENOEXEC error return. So what kind of binary it is and whether or not it will run is pretty much independent of context. It's context free, with the exception of installing the option (treated as an opaque object by the install tools in an ideal world) needed to get the execution environment into the emulation directories and the execution class into the list in the kernel. > The correct thing to do here would be to follow it up, of course. > Which raises another question: how do you debug a COFF program? Easy question. > With a COFF debugger? Yes. > With a kernel debugger? No. Ask yourself "what is a debugging session?". The answer involves knowing how an executable in core image is treated by the system... binaries are treated as virtual address domains, and it doesn't matter the loader format that originated the binary in the first place. You use a COFF debugger because a debugger has to understand the symbol space for the program it's debugging. > Are you saying that writing free software is a justification for doing > it badly? I don't think that's the tenor of this group. The process is different. Not inferior, just different. > Maybe I should remind you of where I'm coming from. I'm not really > very interested in running the thing myself, but I'm writing a book on > installing FreeBSD, and I'm trying to explain this from Joe Schmoe's > viewpoint. So yes, I *do* intend to document the stuff. Again, I'm > not bitching about the quality of the stuff, nor particularly about > the missing documentation. I'm bitching about the attitude "don't > need docs". It would have helped us to know that you were intentionally adopting an obtuse viewpoint up front. Then we could have had a nice, quiet meta-discussion on the merits of the most recent release in that lights, where it falls down, and the fact that there is a huge difference in process in a volunteer effort. And that that is unlikely to change, and that maybe you need to label a bit more of the release code as "experimental" when you write about it, and then go into more detail on it. That would be the logical approach, unless you want to just omit "experimental" stuff as "out of the scope of this document" (a perfectly valid thing to do, though probably not as fun). Notifying us up front rather than adopting proof by exemplar would have put us all on your side in trying to put ourselves in Joe Schmoe's shoes instead of putting us in the position of dealing with "Joe Schmoe, professional adversary". > Enviable? You've obviously never worked much with SCO stuff :-) Yes, > I do have some COFF stuff which I could try out, and I probably will. > I don't understand the question of installation. If you can run COFF > binaries, you should be able to run the installation programs too. Or > am I missing something? The installation programs are part of the IBCS2 environment. They are shell scripts and binaries taken together (at least in the SCO case) and they do a lot more than simply putting programs in the spot they belong. Like key activation, serial number stamping, machine stamping to prevent the installed binary from being easily transportable, other copy protection issues, etc., etc.. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511272104.OAA19524>