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, <flac-dev-requ...@xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev@xiph.org > > 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 > flac-dev-requ...@xiph.org > > You can reach the person managing the list at > flac-dev-ow...@xiph.org > > 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" <tterr...@xiph.org> > To: flac-dev@xiph.org > 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 <robert.kau...@freac.org> > To: flac-dev@xiph.org > 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 <robert.kau...@freac.org> > To: flac-dev@xiph.org > 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 <robert.kau...@freac.org> > To: flac-dev@xiph.org > 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<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" <tterr...@xiph.org> > To: flac-dev@xiph.org > 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<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" <c...@sci.fi> > To: flac-dev@xiph.org > 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<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<http://msdn.microsoft.com/en-US/library/0ys3hc0b%28v=vs.80%29.aspx> > > > > > > ---------- Forwarded message ---------- > From: Ralph Giles <gi...@thaumas.net> > To: flac-dev@xiph.org > 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 > flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > >
_______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev