Which LIBC version under windows!!!!

[Angus Mackay]

> You need to use the Multi-threaded DLL; you can tell because
> you've been thus informed (harder to find out by trial and error).

yes. I know this now. a nicer way to post the answer to how to find out which
version would be:
grep compile_options lib/distutils/msvccompiler.py
  self.compile_options = [ '/nologo', '/Ox', '/MD', '/W3', '/GX' ]

and say that the /MD switch means multi-threaded DLL.


> In the near future they'll give you, and
> other programmers, no choice whatsoever, so you'll be happy.

this is definitly a real mistake. they should never have made more that 1
version of a libc. I would be happy if there was only one (like any UNIX).

> > python should really have thought about passing FILE* pointers between
> > DLLs in terms of Windows and all its suckiness before doing it. I still
> 
> Python gets distracted sometimes, I guess, and absent-mindedly
[snip]
> whine about what whiners use to whine about.  How inconsiderate
> of Python to do otherwise.
> 
> Don't worry.  I'll write a PEP to forbid the passing of FILE* between
> modules, and of course anything that might result in something
> being allocated in one module and freed in another, too

the passing of FILE* pointers is a lot different than memory allocation. I am
pretty sure that even under brain dead windwos the allocation of memory is done
through a common allocator (in kernel.dll or something like that) so even if you
allocate in one DLL and de-allocate in another you will still be okay.

now with FILE* pointers you are talking about the binary layout of a structure,
each user must have intimate knowledge of it to use it and if they are wrong
about what they think it looks like boom!

python makes a lot of statements about being windows friendly but if I get a
static lib from a vendor that requires the non DLL version of libc then I am
just plain screwed. I CAN NOT make a python module that exposes that library.
this would not be so if it weren't for the FILE*'s.

Angus.