else.
Stuart
=20
----- Original Message -----=20
From: Ivailo Karamanolev=20
To: flac-dev at xiph.org=20
Sent: Wednesday, January 06, 2010 7:49 AM
Subject: Re: [Flac-dev] 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>
>> 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
------------------------------------------------------------------------------
_______________________________________________
Flac-dev mailing list
Flac-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
------=_NextPart_000_08BC_01CA8EBE.7CBBBFD0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1"
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18854">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>I haven't done any FLAC
development for some time=20
now, but I've around 25 years experience of working with libc and I
don't really=20
agree with Ben's view.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>You're talking about a
binary compatibility=20
issue and I'd be surprised if Microsoft had changed something in
the=20
library to break it. OS companies usually only break binary compatibility if=20
they absolutely have to. </FONT><FONT size=3D2 face=3DArial>Having
said that, one of=20
the things that is putting me off upgrading to Windows 7 is the fact they=20
have felt the need to include some sort
of "Windows XP emulator".=20
Yes I'm still on Windows XP!!</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>From what you've said I think
you're right that the=20
error is somewhere else.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>Stuart</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT:
0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message -----
</DIV>
<DIV=20
style=3D"FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color:
black"><B>From:</B>=20
<A title=3Divailo91 at gmail.com href=3D"mailto:ivailo91 at
gmail.com">Ivailo=20
Karamanolev</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A
title=3Dflac-dev at xiph.org=20
href=3D"mailto:flac-dev at xiph.org">flac-dev at
xiph.org</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B>
Wednesday, January 06, 2010 7:49=20
AM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B>
Re: [Flac-dev] FLAC C API /=20
Visual Studio 2008 FILE* Issue</DIV>
<DIV><FONT size=3D2 face=3DArial></FONT><FONT size=3D2
face=3DArial></FONT><FONT=20
size=3D2 face=3DArial></FONT><FONT size=3D2
face=3DArial></FONT><BR></DIV>I thought=20
about this, and the MSVCRT mismatch also. What annoys me is that I even
tried=20
compiling the library myself (with exactly the same Visual Studio 2008 as
my=20
application) and the bug didn't change the least. Thank you for your
ideas,=20
but unless someone can confirm this, there still remains the possibility
that=20
I've made an error somewhere. Also someone with more experience with
native=20
debuggers (I'm a kind of .NET man) may be able to detect where the error
comes=20
from more precisely.<BR>About the Windows weirdness - we all want to
program=20
for Linux/Unix only, but even I don't want to use it for my desktop, so
I=20
guess we'll have to deal with Win32.<BR><BR>Ivailo
Karamanolev<BR><BR>
<DIV class=3Dgmail_quote>On Wed, Jan 6, 2010 at 1:15 AM, Ben Allison
<SPAN=20
dir=3Dltr><<A=20
href=3D"mailto:benski at winamp.com">benski at
winamp.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt
0.8ex; PADDING-LEFT: 1ex"=20
class=3Dgmail_quote>Ivailo -<BR><BR>FILE objects are internal
to the C runtime=20
library, they are not system<BR>objects like HANDLEs (windows) or
file=20
descriptors (unix). This means<BR>that if libFLAC has linked
against a=20
different C runtime library than your<BR>application, then the two
FILE=20
objects are incompatible. This isn't just<BR>a Windows
specific issue=20
either - if libFLAC was compiled against libc and<BR>your application
links=20
to glibc (or even a different version of libc) you<BR>will experience
the=20
same issue. In my opinion, this function should
have<BR>never been in=20
the API in the first place. A function that accepts
a<BR>HANDLE on=20
Windows or an int (file descriptor) on Unix is more
appropriate.<BR><BR>-Ben=20
Allison<BR>
<DIV class=3Dim><FONT size=3D2
face=3DArial></FONT><BR>> I managed to get=20
around it. I used the stream functions and provided my<BR>>
own<BR>>=20
callbacks for reading and writing. What's strange is that what
I've=20
done<BR>> is<BR>> just copied the contents of
read/write/seek/tell/eof=20
callbacks from the<BR>> sources to my application and it works
just fine,=20
no glitches. When I use<BR>> the build-in implementation, it
just crashes=20
without any reason. It's not<BR>> a<BR>>
problem to stick with my own=20
callbacks for reading, but fixing this issue<BR>> (if it's
not just me)=20
would be nice.<BR>><BR>> On Wed, Jan 6, 2010 at
12:38 AM, Erik de=20
Castro Lopo<BR></DIV>> <<A=20
href=3D"mailto:mle%2Bla at mega-nerd.com">mle+la at
mega-nerd.com</A><<A=20
href=3D"mailto:mle%252Bla at mega-nerd.com">mle%2Bla at
mega-nerd.com</A>><BR>
<DIV>
<DIV></DIV>
<DIV class=3Dh5>>>
wrote:<BR>><BR>>> Ivailo Karamanolev=20
wrote:<BR>>><BR>>> > I am
currently learning the FLAC C API=20
and had the code working with<BR>>> >=20
FLAC__stream_decoder_init_file. However, since I'd need the=20
Unicode<BR>>> filename<BR>>>
> support, I tried _wfopen_s in=20
combination with<BR>>> >
FLAC__stream_decoder_init_FILE, however I=20
get a runtime crash as sonn<BR>>>
as<BR>>> I<BR>>> >=20
call FLAC__stream_decoder_process_until_end_of_stream. The same=20
code<BR>>> > (partially taken from the examples)
is working
perfectly with the<BR>>>
function<BR>>> > accepting filename=20
and crashing with the one accepting FILE*. I
have<BR>>>=20
tried<BR>>> > both compiling the library myself
and using the=20
precompiled<BR>>> > flac-1.2.1-devel-win. Can
someone try if it is=20
working for him (the<BR>>>
FILE*)<BR>>> > version and if yes=20
- send back the source code?<BR>>> > I work in
Windows 7 64bit, but=20
I tried that also on a virtual Windows<BR>>>
XP<BR>>>=20
and<BR>>> > it crashes there
also.<BR>>><BR>>> There is=20
a whole bunch of weird stuff in windows, this is just
another<BR>>>=20
instance.<BR>>><BR>>> If what you
want to do is read/write FLAC=20
files with windows UCS-16<BR>>>
filenames,<BR>>> one option is=20
to use libsndfile:<BR>>><BR>>>
<A=20
href=3D"http://www.mega-nerd.com/libsndfile/"=20
target=3D_blank>http://www.mega-nerd.com/libsndfile/</A><BR>>><BR>>>=20
which with version 1.0.21 has added this
function:<BR>>><BR>>>=20
/* The function sf_wchar_open() is Windows
Only!<BR>>>=20
** Open a file passing in a Windows Unicode
filename.=20
Otherwise, this<BR>>> is<BR>>>
** the same as=20
sf_open().<BR>>>
**<BR>>> ** In order=20
for this to work, you need to do the following:<BR>>>
=20
**<BR>>> **
=20
#include <windows.h><BR>>>
** =20
#define ENABLE_SNDFILE_WINDOWS_PROTOTYPES
1<BR>>>=20
**
#including=20
<sndfile.h><BR>>>
*/<BR>>> #if=20
ENABLE_SNDFILE_WINDOWS_PROTOTYPES<BR>>>
SNDFILE*=20
sf_wchar_open (LPCWSTR wpath, int mode, SF_INFO *sfinfo)
;<BR>>>=20
#endif<BR>>><BR>>> There is a
windows binary=20
installer in the main web page (one for each<BR>>>
of<BR>>> 32=20
and 64 bit windows).<BR>>><BR>>> The
only downside to this is=20
that libsndfile does not expose the all of<BR>>> the
features of the=20
FLAC API to the user.<BR>>><BR>>>
Erik<BR>>>=20
--<BR>>>=20
----------------------------------------------------------------------<BR>>>=20
Erik de Castro Lopo<BR>>> <A
href=3D"http://www.mega-nerd.com/"=20
target=3D_blank>http://www.mega-nerd.com/</A><BR>>>=20
_______________________________________________<BR>>>
Flac-dev mailing=20
list<BR>>> <A=20
href=3D"mailto:Flac-dev at xiph.org">Flac-dev at
xiph.org</A><BR>>> <A=20
href=3D"http://lists.xiph.org/mailman/listinfo/flac-dev"=20
target=3D_blank>http://lists.xiph.org/mailman/listinfo/flac-dev</A><BR>>><BR>>=20
_______________________________________________<BR>> Flac-dev
mailing=20
list<BR>> <A=20
href=3D"mailto:Flac-dev at xiph.org">Flac-dev at
xiph.org</A><BR>> <A=20
href=3D"http://lists.xiph.org/mailman/listinfo/flac-dev"=20
target=3D_blank>http://lists.xiph.org/mailman/listinfo/flac-dev</A><BR>><BR><BR>_______________________________________________<BR>Flac-dev=20
mailing list<BR><A=20
href=3D"mailto:Flac-dev at xiph.org">Flac-dev at
xiph.org</A><BR><A=20
href=3D"http://lists.xiph.org/mailman/listinfo/flac-dev"=20
target=3D_blank>http://lists.xiph.org/mailman/listinfo/flac-dev</A><BR></DIV></DIV></BLOCKQUOTE></DIV><BR>
<P>
<HR>
<P></P>_______________________________________________<BR>Flac-dev
mailing=20
list<BR>Flac-dev at
xiph.org<BR>http://lists.xiph.org/mailman/listinfo/flac-dev<BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_08BC_01CA8EBE.7CBBBFD0--
