55 lines
2.8 KiB
Plaintext
55 lines
2.8 KiB
Plaintext
Stuff that needs to be done and wishlist:
|
|
|
|
These are in no particular order. A 1.0 release is reliant on doing most of
|
|
this stuff. Some might be dupes, some might be done already.
|
|
|
|
- autoconf support?
|
|
- update the Makefile so that Cygwin can generate a DLL. The entire codebase
|
|
compiles under Cygwin otherwise.
|
|
- Hmm...we can determine the actual CD-ROM drives under Win32, but how do you
|
|
decide that there's no disc in the drive?
|
|
- MacOS (Classic and X) support.
|
|
- Platform-specific functions/macros to handle byte ordering.
|
|
- A PHYSFS_readUint32(), _readSint32(), etc API.
|
|
- Patch the zlib used on win32 to 1.1.4.
|
|
- Switch the CHANGELOG to list newest changes first.
|
|
- Write manpages, preferrably generated from some javadoc-style solution
|
|
so we can make HTML versions etc from the same data.
|
|
- Make internal code respect the new typedefs (PHYSFS_?int??).
|
|
- Byte order API; just something simple like:
|
|
__EXPORT__ PHYSFS_uint16 PHYSFS_swapBE16(PHYSFS_uint16 val);
|
|
__EXPORT__ PHYSFS_uint16 PHYSFS_swapLE16(PHYSFS_uint16 val);
|
|
|
|
(these can be macros. The hard part is determining the architecture at
|
|
compile time, and whether a given platform offers accelerated
|
|
conversion macros already. We can probably jack this from SDL, too.)
|
|
- Make win32.c respect the more strict filesystem layout enforced by
|
|
Win2000 and later.
|
|
- Improve ZIP_seek() (archivers/zip.c)
|
|
- entry_is_symlink() and version_does_symlinks() in zip.c have byte-order bugs.
|
|
- Actually, the zipfile driver could use a lot of tweaking. Please look
|
|
through it.
|
|
- Abstract out the use of stdio. It's not as "std" as I would like, in my
|
|
experience. Add code to the platform drivers to open, read, write, seek,
|
|
tell, etc on an abstract data type that is opaque outside the individual
|
|
platform drivers, so that dir.c has a unified codebase that talks to this
|
|
internal abstraction layer. This opaque data type can be a FILE * on unix,
|
|
and a HANDLE on win32, etc...
|
|
- Other archivers: perhaps tar(.gz|.bz2), RPM, etc. These are less
|
|
important, since streaming archives aren't of much value to games (which
|
|
is why zipfiles are king: random access), but it could have uses for, say,
|
|
an installer/updater. I thought it might be neat to have MBOX and Maildir
|
|
support so that both "archives" look identical to an application; might be
|
|
nice for an email program. That's blue sky, unless someone wants to tackle
|
|
it.
|
|
- Look for FIXMEs (many marked with "!!!" in comments).
|
|
- Port to BeOS (might work already? Will work for sure with autoconf support)
|
|
- Port to MacOS Classic (needs a platform driver, byte order fixes mentioned)
|
|
- Port to MacOS X (specifically, make Project Builder files; unix.c should
|
|
work with it as-is. Might compile as-is with the current Makefile, byte
|
|
ordering fixes mentioned).
|
|
- Probably other stuff. Requests and recommendations are welcome.
|
|
|
|
// end of TODO ...
|
|
|