This is a good idea about zip for library and other files, just one advantage is that it supports folders, and you could (re)define the '~' folders to be loadable from there.
Typically, external data within an executable is maintained as a collection of resources. .NET assembly is a Win32 executable, but then it is also a container for the code library in bytecode form. I have seen instances when DLLs can be included inside one executable file. Possibly these should be resources rather than the zip part. However, there may be a requirement that the dll (j.dll) would go to a separate "resource" portion outside of the library zip. On Mac, the Universal binaries are two executables hosted in one file. So it should be possible to something similar on Mac or even Linux, although haven't heard about such thing. One concern would be to expose the HTML documentation from inside the archive. BTW, if J is used through interop for another host application, such as .NET assembly, that system's mechanism can be used to package up the J portion, including interpreter. --- "Miller, Raul D" <[EMAIL PROTECTED]> wrote: > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
