Devon McCormick wrote: > Conceptually, there ought to be a way to do this but I don't see > how without being able to compile J differently, leaving a hook > to put a script on the end of the executable (and having the DLL > as part of the package).
Conceptually: An executable file is a structured file which has a certain binary prefix. Two particularly ubiquitous prefixes are the PE* of Windows, and Sun's ELF which is use by Linux and other unix operating systems. Also, system calls and other such things are platform specific... and, of course, you need the interpreter internals. So, as a concept, you might have executable files for J, but they would in some sense be platform specific, and basically wind up including a complete copy of the interpreter (and whatever library code). This can get big. Anyways, let's say we go ahead and say that even though executable files are less portable, and bulkier, than J scripts, we want them anyways. Now what? Well, conceptually, a zip file is a structured file which has a certain binary suffix. In other words a file can have dual identity as an executable and as a zip file. This is used in self-extracting executables, but could also be used in J, if we had a way of bootstrapping into a J executable which was also a zip file which also had our .zip content. [As a further aside, the structure used for executables is basically the same structure which is used for libraries, but there tend to be a couple bytes in the file which declares that it's one or the other, which tends to prevent it from being both unless you have your own special implementation of library support.] Anyways, one approach to "make executable J files from inside J" would involve: [a] Pre-baked executable stubs for each major platform [b] Zip file support in J [c] a way of gluing these together You would need to tweak a few values in the executable stubs (offsets, sizes, that kind of thing), and zip file support has analogous requirements. Note that you can have Zip files with uncompressed contents. Supporting packing and unpacking uncompressed zip files would be rather simple to do in J. Especially if you also declared that you would only bother with one of the zip file platform specific conventions. Finally, the J startup code would have to set aside any parameters passed to the executable (because people expect that when they can build an executable that they will be able to pass it startup parameters), and it would have to know to use the zip file support to extract some script and run it. It should probably also have some simple mechanism to extract and run other scripts from the local file. For development purposes, you'd want J to provide you the same interfaces that you'd be using to extract other scripts from the "zip file" but at development time you'd want them coming from some unpacked directory structure. .... Conceptually, that's how I'd approach the problem. FYI, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
