Commit Date  
[r738] (9.9 kB) by theller

Change version to 0.6.10.a1.
Update Copyright statements.

2013-09-07 10:11:45 View
[r726] (9.9 kB) by theller

Work in progress: Using the latest MemoryModule from Joachim Bauch
which works on 64-bit builds.
Still missing: Using binary search in MemoryGetProcAddress.

2013-06-05 18:42:13 View
[r689] (10.0 kB) by mhammond

ensure sys.frozendllhandle is valid in 64bit builds

2011-10-03 23:12:39 View
[r584] (10.0 kB) by mhammond

Correct thread-state errors when a py2exe created executable tries to
use a py2exe created COM DLL.

2005-12-02 05:46:16 View
[r560] (8.8 kB) by theller

Fix compiler warnings.

2005-09-06 19:34:47 View
[r549] (8.7 kB) by theller

Remove unused include.

2005-09-05 18:07:14 View
[r498] (8.8 kB) by theller

Single file executables work (in principle). Still a lot of cleanup to do.

All py2exe run stubs now use runtime dynamic loading of the Python dll.

2005-04-21 19:41:24 View
[r463] (7.9 kB) by theller

Loading pythoncomxx.dll via LoadLibraryEx could never have worked.
The code overwrote the last backslash in the pathname.

2004-11-18 11:32:07 View
[r450] (7.9 kB) by mhammond

Prevent deaklock when a frozen .exe of ours creates a COM object
implemented in our frozen DLL. In that case, Python will already have
been initialized as the COM DLL initializes, so we must do a normal
thread-state dance.

Pending problem in this case is that the Python environment is global - so
once the .exe has created the COM object, sys.frozen will globally reflect
a frozen DLL, which may make the .exe get confused.

2004-08-24 10:15:43 View
[r438] (7.5 kB) by theller

From Mark Hammond: a (fixed) patch to correctly manage the thread state.

2004-07-13 10:00:42 View
[r425] (6.9 kB) by theller

Take out Mark's threadstate patch again - it breaks registering COM dll servers.

2004-07-09 14:37:28 View
[r412] (8.1 kB) by theller

Fix from Mark Hammond, to correctly manage the thread_state.

He writes: Without this patch, the main thread never releases its
thread state - so as soon as another thread tries to call in, it
deadlocks. This pretty-much proves that Outlook callbacks are single
threaded :)

I struck this when building a shell extension DLL. The shell is highly
threaded. I also added a critical section to the init code, just incase 2
threads try and create the first 2 objects at the same time.

2004-06-02 08:14:45 View
[r398] (6.9 kB) by mhammond

We were incorrectly using sys.winver to determine the name of the
pythoncom.dll. Correct this to use the sys.winver tuple.

2004-04-12 02:00:42 View
[r380] (6.8 kB) by theller

Move py2exe from the sandbox directory up to the root dir.

2004-01-16 10:47:02 View