crossplatform py2exe - would it be useful?

Bengt Richter bokr at
Sat Aug 9 00:02:27 CEST 2003

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

>bokr at (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


    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.
     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 ;-)

Bengt Richter

More information about the Python-list mailing list