[physfs] Announcing PhysicsFS 2.0.0!
Ryan C. Gordon
icculus at icculus.org
Mon Mar 23 02:33:59 EDT 2009
Ladies and gentlemen, I present you PhysicsFS 2.0.
Developers using 1.0 are encouraged to upgrade to 2.0; the API is fully
backwards compatible, but adds several new functions, features and
fixes. The 1.0 branch will cease development with the 1.0.2 release, and
2.0 will be the new stable branch.
Source code download:
Grabbing the sources from Mercurial:
hg clone -r release-2.0.0 http://hg.icculus.org/icculus/physfs
PhysicsFS 2.0 offers many improvements over the 1.0 branch.
- New CMake-based build system. The autotools mess is gone, as are all
the specialized project files for various toolchains. We now maintain
one text file that describes the project, and use CMake
(http://www.cmake.org/) to generate real project files from there...it
produces standard Makefiles for most Unixes and BeOS, but also project
files for KDevelop, Xcode, Visual Studio 6/7/8, Watcom, Borland, and
other build tools on Windows and Mac OS X. If your platform or build
tool isn't supported, energy is better spent on enhancing CMake than
creating another project file for PhysicsFS. OS/2 still uses a batch
file to build for now, but everything else is either using CMake or will
- New archiver: lzma support (7zip archives), thanks to Dennis Schridde.
- Unicode support! All PhysicsFS APIs that deal with strings now expect
them to be UTF-8 encoded, and will convert behind the scenes as
appropriate, so eventually your UTF-8 encoded Japanese characters will
become 2-byte WCHAR strings when looking for filenames on a Windows NTFS
disc, etc. Windows will try to use the appropriate codepage on
Win95/98/ME, and use the actual Unicode entry points on NT/XP/Vista,
CFStrings on Mac OS X, etc. The platform layers in PhysicsFS for all
supported OSes are now Unicode clean, except OS/2 (to be considered).
There are new PhysicsFS APIs to provide conversion between some common
- Applications may now supply their own allocators for PhysicsFS to use
internally. If you don't want to supply one, PhysicsFS uses a reasonable
default for the platform (such as malloc() on Unix, or CoreFoundation
APIs on Mac OS X).
- New API: PHYSFS_mount(). This supercedes PHYSFS_addToSearchPath().
This lets you put your archives at specific points in the interpolated
file system. If you have an archive mounted to "/some/subdir" then it
treats it as if every file in that archive is under the /some/subdir
directory (so /path/x.txt will be accessible at
/some/subdir/path/x.txt). Developers can still use
PHYSFS_addToSearchPath() if source/binary compatibility with PhysicsFS
1.0.x is important, and even mix and match calls with PHYSFS_mount().
- New API: PHYSFS_isInit(), to determine if the library is ready for use
when you don't have access to the results of a previous PHYSFS_init() call.
- New API: PHYSFS_symbolicLinksPermitted(), to determine this state when
you don't control the calls to PHYSFS_permitSymbolicLinks().
- Symlinks are now supported on Windows Vista and later:
PHYSFS_isSymbolicLink() and PHYSFS_permitSymbolicLinks() work with the
native filesystem as expected in the new Windows version without losing
binary compatibility with older Windows releases.
- Public headers no longer use size_t, so they work without any system
- Internal mutexes are now recursive on all platforms, which means it's
now safe to call most PHYSFS_* functions from inside an enumeration
callback (including performing more enumerations from inside an
- Added unarchiver program as an example application, which actually
does enumerations from inside enumerations. :)
- Added initial shot at a wxWidgets-based test program, to supersede
test_physfs.c ... still a work in progress.
- Mac OS classic support has been dropped. It could be readded if CMake
is enhanced to support CodeWarrior or MPW, and the code moves from
FSSpec to FSRef functions for Unicode support. Mac OS 8/9 support will
remain in the stable 1.0 branch, and Mac OS X is still, of course, fully
- Improvements to support Cygwin, Mingw32, and MSYS.
- Mac OS X now has its own Carbon-based code, split out from unix.c,
which helps with functionality like Unicode and recursive mutexes...the
bits in posix.c are still used on OS X, though.
- OS/2 now builds with Innotek GCC and klibc instead of EMX (although
can probably still work with EMX).
- Most systems can make do with PHYSFS_init(NULL) now (but still should
have argv for cases where they can't!). This includes Linux and
systems that present a Linux-like /proc filesystem with /proc/self/exe ...
- Compiles on BeOS again (was broken in 1.1.0). Haiku is now a supported
target platform as well.
- On GCC 4 and later, will build with -fvisibility=hidden, so the only
symbols exported from the library are the public APIs. This makes the
library smaller and faster when built as a shared library, not to
mention prevents namespace pollution.
- Reduced malloc pressure a little more (see __PHYSFS_smallAlloc() in
physfs_internal.h). More to come.
- Other bug fixes, cleanups, refactoring, and improvements. A LOT of
internal code has changed...you can check the Mercurial repository
history for specific details.
Please report bugs! Discuss them here or post them in the bug tracker:
More information about the physfs