flac dev - Jan 2010 - FLAC C API / Visual Studio 2008 FILE* Issue

I thought about this, and the MSVCRT mismatch also. What annoys me is that I
even tried compiling the library myself (with exactly the same Visual Studio
2008 as my application) and the bug didn't change the least. Thank you for
your ideas, but unless someone can confirm this, there still remains the
possibility that I've made an error somewhere. Also someone with more
experience with native debuggers (I'm a kind of .NET man) may be able to
detect where the error comes from more precisely.
About the Windows weirdness - we all want to program for Linux/Unix only,
but even I don't want to use it for my desktop, so I guess we'll have to
deal with Win32.

Ivailo Karamanolev

On Wed, Jan 6, 2010 at 1:15 AM, Ben Allison <benski at winamp.com> wrote:
> Ivailo -
>
> FILE objects are internal to the C runtime library, they are not system
> objects like HANDLEs (windows) or file descriptors (unix).  This means
> that if libFLAC has linked against a different C runtime library than your
> application, then the two FILE objects are incompatible.  This isn't
just
> a Windows specific issue either - if libFLAC was compiled against libc and
> your application links to glibc (or even a different version of libc) you
> will experience the same issue.  In my opinion, this function should have
> never been in the API in the first place.  A function that accepts a
> HANDLE on Windows or an int (file descriptor) on Unix is more appropriate.
>
> -Ben Allison
>
> > I managed to get around it. I used the stream functions and provided
my
> > own
> > callbacks for reading and writing. What's strange is that what
I've done
> > is
> > just copied the contents of read/write/seek/tell/eof callbacks from
the
> > sources to my application and it works just fine, no glitches. When I
use
> > the build-in implementation, it just crashes without any reason.
It's not
> > a
> > problem to stick with my own callbacks for reading, but fixing this
issue
> > (if it's not just me) would be nice.
> >
> > On Wed, Jan 6, 2010 at 12:38 AM, Erik de Castro Lopo
> > <mle+la at mega-nerd.com <mle%2Bla at
mega-nerd.com><mle%2Bla at mega-nerd.com<mle%252Bla at
mega-nerd.com>
> >
> >> wrote:
> >
> >> Ivailo Karamanolev wrote:
> >>
> >> > I am currently learning the FLAC C API and had the code
working with
> >> > FLAC__stream_decoder_init_file. However, since I'd need
the Unicode
> >> filename
> >> > support, I tried _wfopen_s in combination with
> >> > FLAC__stream_decoder_init_FILE, however I get a runtime crash
as sonn
> >> as
> >> I
> >> > call FLAC__stream_decoder_process_until_end_of_stream. The
same code
> >> > (partially taken from the examples) is working perfectly with
the
> >> function
> >> > accepting filename and crashing with the one accepting FILE*.
I have
> >> tried
> >> > both compiling the library myself and using the precompiled
> >> > flac-1.2.1-devel-win. Can someone try if it is working for
him (the
> >> FILE*)
> >> > version and if yes - send back the source code?
> >> > I work in Windows 7 64bit, but I tried that also on a virtual
Windows
> >> XP
> >> and
> >> > it crashes there also.
> >>
> >> There is a whole bunch of weird stuff in windows, this is just
another
> >> instance.
> >>
> >> If what you want to do is read/write FLAC files with windows
UCS-16
> >> filenames,
> >> one option is to use libsndfile:
> >>
> >>    http://www.mega-nerd.com/libsndfile/
> >>
> >> which with version 1.0.21 has added this function:
> >>
> >>    /* The function sf_wchar_open() is Windows Only!
> >>    ** Open a file passing in a Windows Unicode filename.
Otherwise, this
> >> is
> >>    ** the same as sf_open().
> >>    **
> >>    ** In order for this to work, you need to do the following:
> >>    **
> >>    **          #include <windows.h>
> >>    **          #define ENABLE_SNDFILE_WINDOWS_PROTOTYPES 1
> >>    **          #including <sndfile.h>
> >>    */
> >>    #if ENABLE_SNDFILE_WINDOWS_PROTOTYPES
> >>    SNDFILE* sf_wchar_open (LPCWSTR wpath, int mode, SF_INFO
*sfinfo) ;
> >>    #endif
> >>
> >> There is a windows binary installer in the main web page (one for
each
> >> of
> >> 32 and 64 bit windows).
> >>
> >> The only downside to this is that libsndfile does not expose the
all of
> >> the features of the FLAC API to the user.
> >>
> >> Erik
> >> --
> >>
----------------------------------------------------------------------
> >> Erik de Castro Lopo
> >> http://www.mega-nerd.com/
> >> _______________________________________________
> >> Flac-dev mailing list
> >> Flac-dev at xiph.org
> >> http://lists.xiph.org/mailman/listinfo/flac-dev
> >>
> > _______________________________________________
> > Flac-dev mailing list
> > Flac-dev at xiph.org
> > http://lists.xiph.org/mailman/listinfo/flac-dev
> >
>
> _______________________________________________
> Flac-dev mailing list
> Flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20100106/0369af38/attachment.htm

Ivailo Karamanolev wrote:
> About the Windows weirdness - we all want to program for Linux/Unix only,
> but even I don't want to use it for my desktop, so I guess we'll
have to
> deal with Win32.
Linux has been my main desktop at home since 1995 and my main desktop
at work since 2000. I wouldn't have it any other way.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

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!!

On Wed, 2010-01-06 at 09:49 +0200, Ivailo Karamanolev
wrote:
> I thought about this, and the MSVCRT mismatch also. What annoys me is
> that I even tried compiling the library myself (with exactly the same
> Visual Studio 2008 as my application) and the bug didn't change the
> least. Thank you for your ideas, but unless someone can confirm this,
> there still remains the possibility that I've made an error somewhere.
> Also someone with more experience with native debuggers (I'm a kind
> of .NET man) may be able to detect where the error comes from more
> precisely.
Is there any possibility that there are two versions of the FILE *
structure in the run time library and that which one you get depends on
some compile time option like, for example, the length of file offsets
or the width of the character set used either for the filenames or in
the character-based functions.

If that is the case you'd need to explore whether either your code or
the FLAC library is forcing the use of a version other than the default
and that then means the two pieces of code are using different versions
of the structure?

When you copy the callbacks into your own code they obviously get
compiled with the same compile time options as the rest of your code.

Regards,
Steve.

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.