Building on Windows with a runtime other than the one Python uses makes Enso not work

[blackdaemon]

Reported by unfocused, Mar 21, 2008

What steps will reproduce the problem?
1. Build on Windows, linking to a dynamically loaded runtime other than the
one Python uses
2. Run Enso
3. Fail to start - due to different dynamically loaded runtimes in the same
process (fails with cryptic error message)

What is the expected output? What do you see instead?
At the moment, stuff is built with the dynamically loaded multi-threaded
runtime (compiler switch /MD). It should be built with a statically linked
runtime (compiler switch /MT), so that Enso can be run no matter how Python
was built.

What version of the product are you using? On what operating system?
Windows.

[blackdaemon (blackdaemon)]

Comment 1 by varmaa, Mar 24, 2008

IIRC, the potential problem with this approach is that it means that two separate
instances of the C runtime exist in the same process space. This means that certain
things, like file pointers, can't be exchanged from one CRT instance to another--or
rather, they *can* be exchanged, but it'll cause a segfault. I believe that we
encountered this fairly early on in Enso development, but I'm not 100% sure. I was
also under the impression that the reason C extension modules like pywin32 require
you to download a different installer depending on your version of Python was due to
this issue.

Are there any major Python C extension modules that statically include the CRT like this?

[blackdaemon (blackdaemon)]

Comment 2 by unfocused, Mar 24, 2008

Yes, I realise that was a major hack - but it was a required hack to get it working
quick and easy. Even if it was a Bad Thing (tm).

I just recompiled without linking to CRT (no /MD or /MT - used /LD instead), and
everything seems to be working fine.

Needs to be really tested - but maybe we can skip out CRT altogether?