Upgrading Python Breaks Extensions; Fix proposal

[Gordon McMillan]

Greg Ewing wrote: 

> Skip Montanaro wrote:
>> 
>> I might be reading this wrong, and I'm definitely taking you out of
>> context, but the whole idea of .so files is that their text sections
>> *are* shared among processes.  Their data sections will be
>> process-private. 
> 
> I think the difference lies in whether the parts of the
> code that need to be changed to fix external references
> are per-process or shared. On Unix they're per-process,
> so each instance of the shared library can have its
> own set of references back to the program which is
> using it. On Windows they're apparently shared.

Windows dlls haven't been shared since Win3.1. You can share
memory through a dll, but that's because Windows has calls
that let you allocate memory out of Window's process space.

There are lots of differences to .so's. The fix-ups are very
simplistic - an exported symbol is just a name, ordinal and
(relative) address. When you build a dll, you also get a lib. 
It's really a stub that loads the dll and does the fix ups.

The difference that is germain to this thread is that while
you can export symbols from an exe, you don't get a lib.
So to get to the symbols in the exe, you'd have to do it
yourself, which means a typedef and a GetProcAddress for each
symbol. Which makes the TCL stubs idea look very good.

There's a reason extension modules only need to export
one symbol, you know.

- Gordon