From: Austin Ziegler Date: 2007-12-13T22:20:35+09:00 Subject: Re: [Spam] Re: What's the status of compiler/compiling on windows? On 12/13/07, Luis Lavena wrote: > On Dec 13, 2007 3:57 AM, Joe Swatosh wrote: > > On Dec 12, 2007 1:55 PM, Austin Ziegler wrote: > > > And the *reason* it's not a theoretical scenario is that Unix doesn't > > > have this problem (multiple runtimes) in > 99% of cases. Most Unixes > > > only have one runtime installed and cannot actually have another > > > runtime installed. Therefore, there's not multiple heaps involved. > > > Therefore, it's a common case to have an API that says "this C call > > > allocates memory; remember to free it when you're done with it." There > > > should be an library_api_free call for every library (e.g., zlib_free, > > > openssl_free, etc.) just in case, but it's Not An Issue on Unix. > > If everyone used ruby_xmalloc and ruby_xfree, would this part of the binary > > extension problem be addressed? > If memory plays well with my age, I think perl guys created a > PerlCRT.dll back in 2001 to workaround the CRT issues. > > The extensions (even perl.exe) was linked against it and thus, > avoiding the msvcr* dilemma. Yikes. That doesn't seem pretty. There are two real (long-term) solutions for this: Microsoft needs to fix its behaviour so that you can have a MSVCRT (VC6) linked program actually using MSVCRT80 (VC8) without knowing it; bugs need to be filed against external libraries that don't provide their own resource management operations (e.g., need _{malloc,free,errno,fopen,fclose}). -austin -- Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca