On 1/6/2010 18:53, Stuart Fisher wrote:> I haven't done any FLAC development for some time now, but I've around 25 years experience of working with libc and I don't really agree with Ben's view. > > You're talking about a binary compatibility issue and I'd be surprised if Microsoft had changed something in the library to break it. OS companies usually only break binary compatibility if they absolutely have to. Having said that, one of the things that is putting me off upgrading to Windows 7 is the fact they have felt the need to include some sort of "Windows XP emulator". Yes I'm still on Windows XP!! > >> From what you've said I think you're right that the error is somewhere else. > > Stuart >Hi, Ben is likely talking about various versions of the MS runtime. MSVCRT.DLL != MSVCR90.DLL != MSVCR80.dll and so on. Only MSVCRT.DLL, that comes with nearly all win32 machines needs to maintain backwards ABI compatibility across different versions. MSVC2008 uses MSVCR90.DLL, so it doesn't need to maintain ABI compatibility with MSVCRT.DLL.
Stuart Fisher
2010-Jan-06 14:04 UTC
[Flac-dev] FLAC C API / Visual Studio 2008 FILE* Issue
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!. ----- Original Message ----- From: "JonY" <jon_y at users.sourceforge.net> To: <flac-dev at xiph.org> Sent: Wednesday, January 06, 2010 12:09 PM Subject: Re: [Flac-dev] FLAC C API / Visual Studio 2008 FILE* Issue> On 1/6/2010 18:53, Stuart Fisher wrote: >> I haven't done any FLAC development for some time now, but I've around 25 >> years experience of working with libc and I don't really agree with Ben's >> view. >> >> You're talking about a binary compatibility issue and I'd be surprised if >> Microsoft had changed something in the library to break it. OS companies >> usually only break binary compatibility if they absolutely have to. >> Having said that, one of the things that is putting me off upgrading to >> Windows 7 is the fact they have felt the need to include some sort of >> "Windows XP emulator". Yes I'm still on Windows XP!! >> >>> From what you've said I think you're right that the error is somewhere >>> else. >> >> Stuart >> > > Hi, > > Ben is likely talking about various versions of the MS runtime. > MSVCRT.DLL != MSVCR90.DLL != MSVCR80.dll and so on. > > Only MSVCRT.DLL, that comes with nearly all win32 machines needs to > maintain backwards ABI compatibility across different versions. > > MSVC2008 uses MSVCR90.DLL, so it doesn't need to maintain ABI > compatibility with MSVCRT.DLL. > _______________________________________________ > Flac-dev mailing list > Flac-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > > >
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.