However... there is this py2exe project, which has just done that: implemented custom win32 DLL loader (PE loader). And it's open source.
See how it works http://py2exe.cvs.sourceforge.net/py2exe/py2exe/source/README-MemoryModule.txt?revision=1.1 They are able to create a bundle with python interpreter DLL, library as a zip, and the program scripts, all into a single EXE. --- Oleg Kobchenko <[EMAIL PROTECTED]> wrote: > Here is a overview of possible ways to pack > native DLLs into one EXE file. > > http://madebits.com/netz/native.php > > .NETZ is a free open source tool that compresses and packs > several .NET assembly DLLs into a single EXE file. > > The conclusion is that packing native DLLs (unlike .NET assemblies) > is a complicated and dubious process with many limitations, > it's not portable and only available with commercial tools. > > So it makes more sence to use separate J runtime or > installation and separate product distribution, which > itself can be extractable installation or a single zip bundle. > Closed source can be made with locked scripts. > > > --- "Miller, Raul D" <[EMAIL PROTECTED]> wrote: > > > Oleg Kobchenko wrote: > > > I have seen instances when DLLs can be included inside > > > one executable file. Possibly these should be resources > > > rather than the zip part. > > > > Yes, conceptually, ELF and PE* both can represent multiple > > "files", much like .ZIP. The advantage of .ZIP is that it's > > supported across across platforms. > > > > > > > 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. > > > > I'm dubious about this being supported on systems other > > than Mac. > > > > > One concern would be to expose the HTML documentation > > > from inside the archive. > > > > Option 0: don't bother. Put HTML documentation up on > > the web, and refer to it by url. > > > > Option 1: unpack html documentation and make it available > > as indpendent files, when needed. > > > > Option 2: for OSes that give a file system interface for > > zip contents, just use the file in place. [Another advantage > > of .zip over other formats is that this kind of thing does > > exist for zip -- though it's by no means universal.] > > > > > 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. > > > > Yes, but getting J scripts to the interpreter is going > > to require calling out to the other environment to > > get them. Which, while certainly doable, could be > > a minor annoyance. > > > > And, of course, this only works for people who invest > > time and energy in those other tools. > > > > -- > > Raul ____________________________________________________________________________________ Get your email and see which of your friends are online - Right on the New Yahoo.com (http://www.yahoo.com/preview) ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
