It's not that hard to repackage it, is it?
Here you go: www.icer.nl/misc_stuff/flac.xcodeproj .zip
On 06-05-13 23:37, Marcus Johnson wrote:
Ralph, for Mac OS you should download either the Unarchiver which is
free, or Entrophy which is what I use, but it costs like $15 I
believe, both support decompressing .7z and Entrophy supports
compressing TO .7z
On Mon, May 6, 2013 at 3:00 PM, <[email protected]
<mailto:[email protected]>> wrote:
Send flac-dev mailing list submissions to
[email protected] <mailto:[email protected]>
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.xiph.org/mailman/listinfo/flac-dev
or, via email, send a message with subject or body 'help' to
[email protected] <mailto:[email protected]>
You can reach the person managing the list at
[email protected] <mailto:[email protected]>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of flac-dev digest..."
Today's Topics:
1. Re: Bug fix and compatibility patches for 1.3.0pre4
(Timothy B. Terriberry)
2. Re: Bug fix and compatibility patches for 1.3.0pre4
(Robert Kausch)
3. Re: Bug fix and compatibility patches for 1.3.0pre4
(Robert Kausch)
4. Re: Bug fix and compatibility patches for 1.3.0pre4
(Robert Kausch)
5. Re: Bug fix and compatibility patches for 1.3.0pre4
(Timothy B. Terriberry)
6. Re: Bug fix and compatibility patches for 1.3.0pre4
(Janne Hyv?rinen)
7. Re: (no subject) (Ralph Giles)
---------- Forwarded message ----------
From: "Timothy B. Terriberry" <[email protected]
<mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Cc:
Date: Sun, 05 May 2013 14:43:46 -0700
Subject: Re: [flac-dev] Bug fix and compatibility patches for
1.3.0pre4
Janne Hyvärinen wrote:
You people do realize these hacks would only be required for
10+ year
old obsolete compilers?
No, they're required for easy distribution on 12 year old OSes
(which, last I saw, make up almost 40% of Firefox's desktop
userbase, and likely will continue to for some time).
---------- Forwarded message ----------
From: Robert Kausch <[email protected]
<mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Cc:
Date: Mon, 06 May 2013 01:20:52 +0200
Subject: Re: [flac-dev] Bug fix and compatibility patches for
1.3.0pre4
Timothy B. Terriberry wrote:
_lseeki64 operates on the underlying file handle, and does not
interact
well with the buffering in stdio streams. I _think_ you can
use this
successfully if you call fflush() beforehand (as this sets
FILE::_cnt to
0 and FILE::_ptr to FILE::_base). By which I mean I read the
MSVCRT
source from MSVC6.0 and it appears this is how things work.
Ok, I didn't take that into account. Thanks for pointing it out!
Using fflush to clear the buffers before calling _lseeki64 sounds
reasonable, so I think I'll try that.
I noticed another problem with _lseeki64 though. It returns the
new file pointer position on success instead of 0, so the macro
will have to take that into account.
That source also includes an fseeki64()/ftelli64(), but they
are not
defined in stdio.h. I wonder if just declaring it yourself is good
enough?
Those functions are not exported by XPs msvcrt.dll, so declaring
them won't help.
---------- Forwarded message ----------
From: Robert Kausch <[email protected]
<mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Cc:
Date: Mon, 06 May 2013 01:21:56 +0200
Subject: Re: [flac-dev] Bug fix and compatibility patches for
1.3.0pre4
JonY wrote:
How about just forgetting about base XP and require at least
SP2 or some
such? Alternatively, use win32api underneath instead, eg
CreateFileW/SetFilePointer.
Even SP2 and SP3 do not have fseeki64/ftelli64. Using Windows API
functions would probably be the cleanest solution, but on the
other hand require wrappers for all file IO functions. I guess
that would be too big of a change to make it into 1.3.0 at this point.
---------- Forwarded message ----------
From: Robert Kausch <[email protected]
<mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Cc:
Date: Mon, 06 May 2013 01:26:08 +0200
Subject: Re: [flac-dev] Bug fix and compatibility patches for
1.3.0pre4
Timothy B. Terriberry wrote:
Instead I've attached a patch that uses fgetpos/fsetpos. This
is totally untested (I haven't even checked it compiles), but
the idea should work.
MSDN says "The pos value is stored in an internal format and is
intended for use only by *fgetpos* and *fsetpos*."
(http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx),
so I don't think it's a good idea to use it this way even if tests
suggested it works.
I'll write a test program tomorrow to try the fflush+_lseeki64
approach.
Another solution - although a bit ugly - might be to disable
buffering on Windows using setvbuf.
---------- Forwarded message ----------
From: "Timothy B. Terriberry" <[email protected]
<mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Cc:
Date: Sun, 05 May 2013 16:34:04 -0700
Subject: Re: [flac-dev] Bug fix and compatibility patches for
1.3.0pre4
Robert Kausch wrote:
MSDN says "The pos value is stored in an internal format and
is intended
for use only by *fgetpos* and *fsetpos*."
(http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx),
so
I don't think it's a good idea to use it this way even if tests
suggested it works.
FWIW, I verified that this is the approach used by mingw32 to
implement fseeko/ftello.
---------- Forwarded message ----------
From: "Janne Hyvärinen" <[email protected] <mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Cc:
Date: Mon, 06 May 2013 07:42:34 +0300
Subject: Re: [flac-dev] Bug fix and compatibility patches for
1.3.0pre4
On 6.5.2013 0:43, Timothy B. Terriberry wrote:
Janne Hyvärinen wrote:
You people do realize these hacks would only be required
for 10+ year
old obsolete compilers?
No, they're required for easy distribution on 12 year old OSes
(which,
last I saw, make up almost 40% of Firefox's desktop userbase,
and likely
will continue to for some time).
What kind of nonsense is this? You should know that the last
Microsoft compiler to create dynamically linked code that used
msvcrt.dll was Visual Studio 6.0 from 1998.
Oldest Visual Studio supported by FLAC 1.3 is Visual Studio 2005.
FLAC is also configured to be compiled with static linking, so no
external dependencies hinder its function.
If you take a look at the following MSDN pages for Visual Studio
2005, you will see that _fseeki64 and _ftelli64 are supported all
the way back to Windows 95:
http://msdn.microsoft.com/en-us/library/75yw9bf3%28v=vs.80%29.aspx and
http://msdn.microsoft.com/en-US/library/0ys3hc0b%28v=vs.80%29.aspx
---------- Forwarded message ----------
From: Ralph Giles <[email protected] <mailto:[email protected]>>
To: [email protected] <mailto:[email protected]>
Cc:
Date: Mon, 06 May 2013 11:20:15 -0700
Subject: Re: [flac-dev] (no subject)
On 13-05-02 7:37 PM, Marcus Johnson wrote:
> Here's the Flac.xcodeproj, compressed with 7-zip as it's just a
folder
> and can't be transmitted without being compressed, check to see
if it
> works on your computers, and hopefully everything works.
.7z isn't a normal MacOS tool. Could you please send a tar.gz or .zip
instead?
-r
_______________________________________________
flac-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.xiph.org/mailman/listinfo/flac-dev
_______________________________________________
flac-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/flac-dev
_______________________________________________
flac-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/flac-dev
