
Gordon McMillan wrote:
OK - os.path.dirname(sys.argv[0]).
Oh, I see. Your main program is given as a complete path in the icon target. So "python D:/my/path/myprog.py". I start my main as the frozen module named "__main__", so sys.argv[0] is useless.
In my case it doesn't matter. I have just concatenated my archive (of python15.dll, any .pyzs, exceptions.py, site.py etc.) onto the end of the executable. When run, it opens itself as a file and unpacks the archive into the current directory. Then it does a _putenv("PYTHONPATH=.") and dynamically loads python15.dll. If you're using Run.exe, it even cleans up whatever it unpacked at end of run.
Cool. I didn't realize you could append to an .exe and still have it run. How do you know where your appended data starts?
More advanced would be to make the archive a legit resource section of the exe, but I can't see that as worth the effort (esp. since I don't expect my users to have compilers, and I've already gone to the work of finding the import sections in dll headers so I can find binary dependencies...)
I think this may be a good idea. We could use a Windows user-defined resource named with a magic name such as "PythonPyc", and all resource modules could be loaded in Py_Initialize(). The .rc resource file names the .pyc file so there is no need to convert the bytes to C and compile. The .rc file syntax is the line: string PythonPyc C:/lib/string.pyc You use FindResource(), SizeofResource(), LoadResource() and LockResource() to access these resources. It is possible to replace resources in an exe or dll using BeginUpdateResource(), UpdateResource() and EndUpdateResource(). If we wrote a Python interface into a .pyd, then users don't even need a compiler nor resource compiler. Note that there is Mac code in the distribution which accesses Mac resources. The only reason I have not written all this is it is not usable on Unix. Jim Ahlstrom