win32 python as a dll?

[Scott Wolford]

Gordon McMillan wrote:

>  > How about:
> > python.lib/dll and msvcrt.lib/dll
> > python.lib/dll and msvcrtd.lib/dll
> > python_d.lib/dll and msvcrt.lib/dll
> > python_d.lib/dll and msvcrtd.lib/dll
>
> Debug python linked to non-debug msvcrt makes sense - means you can
> load non-debug extension modules (see below).

Exactly my point; hence the four combos (or two if you don't want to give out
python15_d.dll).

> > > It is also worth noting that Gordon pointed this out to you before this
> > > particular thread, and you still had the problem.  Im not sure that
> > > documenting it would be effective in all cases.
> >
> > He said to use the Multithreaded DLL. Unfortunately, msvcrt.dll and
> > msvcrtd.dll are *both* the Multithreaded DLL; one is debug the other
> > is not. It never occured to me (well, it finally did) that it
> > mattered whether msvcrt.dll or msvcrtd.dll were used. I assumed that
> > the semantics of the two DLLs were essentially the same, just the
> > implementation differed slightly. I'm pretty sure (though I haven't
> > tested it, maybe you'll know) that you can mix and match optimized
> > and debug code pretty easily under Unix.
>
> To beat a dead horse into an unrecognizable pulp:
>
> That's the whole point - they are *different* dlls. So a file open in
> one will not be found in the other. Kaboom. Nothing to do with
> semantics - it's just where buffers, files and other statics /
> globals live.

I guess I didn't pose my question properly. Under Unix, can you not link with a
debug foo.so at link-time, then at run-time load an optimized version, as long
as the code used to generate the two is roughly the same? It seems to work for
me. Why can't you do the same thing under Windows?

> You can mix debug and optimized in Windows, too - you'll just end up
> stepping thru unintelligable assembler when you hit non-debug code.

That's not what I meant and I know that.

> [And for the masochistically curious - the reason the runtime lib is
> specified to the MSVC compiler and not the linker is that the
> compiler generates slightly different code depending on whether the c
> runtime is in a static lib or in a dll.]

I still don't see why you have to jump through these hoops just to get simple
stuff working on Windows.