Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
45 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,17 +1,54 @@ | ||
Stuff that needs to be done and wishlist: | ||
|
||
- autoconf? | ||
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. | ||
- Move the integer types to something abstract. uint32, etc. | ||
- Platform-specific functions/macros to handle byte ordering. | ||
- A PHYSFS_readUint32(), _readSint32(), etc API. | ||
- Ditch the "standard" i/o routines (fopen() and friends) and move this into | ||
the platform drivers. | ||
- 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); | ||
|
||
// end of TODO ... | ||
(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 ... | ||
|