[Flac-dev] FLAC C API / Visual Studio 2008 FILE* Issue

[JonY]

On 1/6/2010 22:04, Stuart Fisher wrote:
> Now that you mention it I remember many years ago having a compatibility
> issue with some app we'd written. As I recall we had to get our
> customers to install msvcr70.dll because none of their machines had it
> (this was in the days of NT4). That dll came with the version of Visual
> Studio we were using but of course none of our customers had Visual
> Studio installed!
>
> I guess Microsoft is off the hook then. Changing the name of the dll
> every release allows you make major changes, but it's not a very user
> friendly way of doing things. You end up with a whole lot of dlls
> containing the same functionality. :-(
>
> Getting back to the original problem, Steve's reasoning sounds like a
> possible explanation. Wide character and long filename support was
> something that was defnitely added later. I wouldn't be surprised if
> that meant yet another runtime dll!.
>
>

Hi,

MSVCRT.DLL does change too, but I'm sure MS tries hard to maintain ABI.
For example, _wfopen isn't available in Win9X, but available to NT4 and
other modern NT based systems.

In any case, sharing of opaque data between different runtimes is a bad
idea. There is also a similar issue with memory allocators like
malloc/free, freeing data at the wrong side will likely cause crash. :(

Like an earlier mentioned, using callbacks is a guaranteed way that
these opaque data is only accessed by the correct runtime version,
since the same compiler is used to build the callback code and app.

Steve too mentions about compile options, but I don't know MSVC well
enough to help out.