crossplatform py2exe - would it be useful?

[Bengt Richter]

On Fri, 08 Aug 2003 21:52:45 +0200, Thomas Heller <theller at python.net> wrote:

>bokr at oz.net (Bengt Richter) writes:
>
>> PMJI, since I haven't read all the prior thread, but if the point is
>> just to have an executable that self-unpacks and starts, IWT the safest
>> (for platform independence -- not security, see my conclusion later below)
>> approach would be to have a tool that makes a light-weight self-unpacking
>> "exe" wrapper for any/each platform.
>
>No, that's not the goal (at least not for me). I don't want to unpack
>something at runtime, I want exactly that what py2exe currently does:
>One executable, plus maybe a handful of files (.dll/.pyd/.so).
>
That "plus" makes for a little ambiguity ;-)

Is there a big difference for you between e.g.,

    wget <some url>/py2exefiedapp.exe
    py2exefiedapp

and

    wget <some url>/py2exefiedapp.uff
    uffunwrap --launch exefiedapp.uff

??
I don't think you'd see much difference in speed between a single exe with tacked-on baggage
or a single .uff file launched with uffunwrap --launch.

(BTW, changed my mind to .uff for Universal File Format -- it's easier to type ;-)

(you could make a .uff automatic association on windows, and if you wanted a single-file
launch on unix, you could prefix a line like #!/usr/bin/uffunwrap --launch)

Especially if you can type

    ufhunwrap --header exefiedapp.uff

and see something like

    Date: Fri, 08 Aug 2003 21:52:45 +0700
    Author: B. Richter
    Status: Preliminary. Could use ideas for conventions in this header.
    Description:
     This package will if launched will unpack in the current directory and run.
     It does all kinds of neat things, trust me .... ;-)
    License: PSF
    X-Launch: ./py2exefiedapp.exe -cfg ./myConfig.txt
    X-UFF-Packing: endian=little pktframes=none align=8 # take lengths from this hdr, expect pad to %8=0
     1: b 3456780 ./py2exefiedapp.exe  2003-08-08 22:00:00 +0700  md5=0123456789abcdef...
     2: b  123458 ./dlls/mySpecialGizmo.dll ...
     3: t     456 ./myConfig.txt ...
     ...

the idea is a simple flat list of contents with sizes and binary/text indications and
where-to-put-them paths with a numbered list of segments in the .uff file (zero is the header itself).
You can see how easy it would be to unpack such a file. I'm tempted to write it before posting this ;-)

You can see also that the X-Launch: line can permit doing just about anything. It would not be
hard to package up a special version of python.exe and some dll's and with
X-Launch: python -OO whatever, then uffunwrap --launch (I think I'd soon alias that to uff -x ;-)
would simply start whatever is in the X-Launch line.

you could also type
    uffunwrap --check exefiedapp.uff
to get all the available checksums checked and others reported

You could have an option to use existing files or overwrite them, etc. I think I will write one
of these in any case. Maybe you will like the result better as a reality ;-)


>> I think it would be relatively trivial on win32. I think you could do it all
>> in Python once you have a little C boilerplate exe template compiled and a
>> few special locations and segments defined (i.e., .exe's have provision
>> for simple embedded resource entities.
>
>Well, for PE files on win32, the special locations can easily be stored
>as resources, but IIUC that's not possible under Linux, for example.
>But appending random stuff at the end of a valid executable is possible there.
>
>> For that purpose, I've been thinking a unicode utf-8 representation of
>> an rfc2822 header might be cool.
>
>Ok, once you can execute Python code, you can do very fancy stuff. But
>the problem is to 'boot' the Python interpreter into existance, the
>first setp of this must be done from C code, and so it must be as simple
>as possible.
I am confident (FLW ;-) that I can write a small fast unwrapper/launcher in C
along the lines of the above for win32. I think it will port well, except for
the actual executable-launch part.

If you insist, I can write the win32 version to allow tack-on resources ;-)

Regards,
Bengt Richter