<div dir="ltr">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</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 6, 2013 at 3:00 PM, <span dir="ltr"><<a href="mailto:flac-dev-request@xiph.org" target="_blank">flac-dev-request@xiph.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send flac-dev mailing list submissions to<br>
<a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.xiph.org/mailman/listinfo/flac-dev" target="_blank">http://lists.xiph.org/mailman/listinfo/flac-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:flac-dev-request@xiph.org">flac-dev-request@xiph.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:flac-dev-owner@xiph.org">flac-dev-owner@xiph.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of flac-dev digest..."<br>
<br>Today's Topics:<br>
<br>
1. Re: Bug fix and compatibility patches for 1.3.0pre4<br>
(Timothy B. Terriberry)<br>
2. Re: Bug fix and compatibility patches for 1.3.0pre4<br>
(Robert Kausch)<br>
3. Re: Bug fix and compatibility patches for 1.3.0pre4<br>
(Robert Kausch)<br>
4. Re: Bug fix and compatibility patches for 1.3.0pre4<br>
(Robert Kausch)<br>
5. Re: Bug fix and compatibility patches for 1.3.0pre4<br>
(Timothy B. Terriberry)<br>
6. Re: Bug fix and compatibility patches for 1.3.0pre4<br>
(Janne Hyv?rinen)<br>
7. Re: (no subject) (Ralph Giles)<br>
<br><br>---------- Forwarded message ----------<br>From: "Timothy B. Terriberry" <<a href="mailto:tterribe@xiph.org">tterribe@xiph.org</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>
Cc: <br>Date: Sun, 05 May 2013 14:43:46 -0700<br>Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4<br>Janne Hyvärinen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You people do realize these hacks would only be required for 10+ year<br>
old obsolete compilers?<br>
</blockquote>
<br>
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).<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Robert Kausch <<a href="mailto:robert.kausch@freac.org">robert.kausch@freac.org</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>
Date: Mon, 06 May 2013 01:20:52 +0200<br>Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4<br>Timothy B. Terriberry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_lseeki64 operates on the underlying file handle, and does not interact<br>
well with the buffering in stdio streams. I _think_ you can use this<br>
successfully if you call fflush() beforehand (as this sets FILE::_cnt to<br>
0 and FILE::_ptr to FILE::_base). By which I mean I read the MSVCRT<br>
source from MSVC6.0 and it appears this is how things work.<br>
</blockquote>
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.<br>
<br>
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.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That source also includes an fseeki64()/ftelli64(), but they are not<br>
defined in stdio.h. I wonder if just declaring it yourself is good<br>
enough?<br>
</blockquote>
Those functions are not exported by XPs msvcrt.dll, so declaring them won't help.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Robert Kausch <<a href="mailto:robert.kausch@freac.org">robert.kausch@freac.org</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>
Date: Mon, 06 May 2013 01:21:56 +0200<br>Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4<br>JonY wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How about just forgetting about base XP and require at least SP2 or some<br>
such? Alternatively, use win32api underneath instead, eg<br>
CreateFileW/SetFilePointer.<br>
</blockquote>
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.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Robert Kausch <<a href="mailto:robert.kausch@freac.org">robert.kausch@freac.org</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>
Date: Mon, 06 May 2013 01:26:08 +0200<br>Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4<br>Timothy B. Terriberry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
MSDN says "The pos value is stored in an internal format and is intended for use only by *fgetpos* and *fsetpos*." (<a href="http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx" target="_blank">http://msdn.microsoft.com/en-<u></u>us/library/70hdhh4t%28v=vs.80%<u></u>29.aspx</a>), so I don't think it's a good idea to use it this way even if tests suggested it works.<br>
<br>
I'll write a test program tomorrow to try the fflush+_lseeki64 approach.<br>
<br>
Another solution - although a bit ugly - might be to disable buffering on Windows using setvbuf.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: "Timothy B. Terriberry" <<a href="mailto:tterribe@xiph.org">tterribe@xiph.org</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>
Cc: <br>Date: Sun, 05 May 2013 16:34:04 -0700<br>Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4<br>Robert Kausch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
MSDN says "The pos value is stored in an internal format and is intended<br>
for use only by *fgetpos* and *fsetpos*."<br>
(<a href="http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx" target="_blank">http://msdn.microsoft.com/en-<u></u>us/library/70hdhh4t%28v=vs.80%<u></u>29.aspx</a>), so<br>
I don't think it's a good idea to use it this way even if tests<br>
suggested it works.<br>
</blockquote>
<br>
FWIW, I verified that this is the approach used by mingw32 to implement fseeko/ftello.<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: "Janne Hyvärinen" <<a href="mailto:cse@sci.fi">cse@sci.fi</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>Date: Mon, 06 May 2013 07:42:34 +0300<br>
Subject: Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4<br>On 6.5.2013 0:43, Timothy B. Terriberry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Janne Hyvärinen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You people do realize these hacks would only be required for 10+ year<br>
old obsolete compilers?<br>
</blockquote>
No, they're required for easy distribution on 12 year old OSes (which,<br>
last I saw, make up almost 40% of Firefox's desktop userbase, and likely<br>
will continue to for some time).<br>
<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<a href="http://msdn.microsoft.com/en-us/library/75yw9bf3%28v=vs.80%29.aspx" target="_blank">http://msdn.microsoft.com/en-<u></u>us/library/75yw9bf3%28v=vs.80%<u></u>29.aspx</a> and<br>
<a href="http://msdn.microsoft.com/en-US/library/0ys3hc0b%28v=vs.80%29.aspx" target="_blank">http://msdn.microsoft.com/en-<u></u>US/library/0ys3hc0b%28v=vs.80%<u></u>29.aspx</a><br>
<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Ralph Giles <<a href="mailto:giles@thaumas.net">giles@thaumas.net</a>><br>To: <a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>Cc: <br>Date: Mon, 06 May 2013 11:20:15 -0700<br>
Subject: Re: [flac-dev] (no subject)<br>On 13-05-02 7:37 PM, Marcus Johnson wrote:<br>
> Here's the Flac.xcodeproj, compressed with 7-zip as it's just a folder<br>
> and can't be transmitted without being compressed, check to see if it<br>
> works on your computers, and hopefully everything works.<br>
<br>
.7z isn't a normal MacOS tool. Could you please send a tar.gz or .zip<br>
instead?<br>
<br>
-r<br>
<br>
<br>
<br>_______________________________________________<br>
flac-dev mailing list<br>
<a href="mailto:flac-dev@xiph.org">flac-dev@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/flac-dev" target="_blank">http://lists.xiph.org/mailman/listinfo/flac-dev</a><br>
<br></blockquote></div><br></div>