No subject
Mon Nov 3 13:03:41 PST 2008
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>><B=
R>
<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>&=
gt;>=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>&g=
t;><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>&g=
t;<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--
More information about the Flac-dev
mailing list