Hello,
I’m working on a filesystem access library for SDL. Currently it works
under Linux, but I haven’t enough time to support Win32 and other
versions. Would anybody like to help with the other ports? (Would
anybody even need such a library?)
The library has no page right now, but I can set up a sourceforge
project if there is some interest in it.
Have a nice day and lotsa sunshine,
Jiri “BlueBear” Dluhos (dluhosj at centrum dot cz)
I’m a Win32 developer, so I’m willing to try compiling it and to spend
about 30 minutes to try to make it compile if it doesn’t work right
away. If all is successful, I’ll send you the compiled binaries with
any changes to the code.
Olivier A. Dagenais - Software Architect and Developer
“Jiri Dluhos” wrote in message
news:3AD6EC55.535552F5 at humusoft.com…
Hello,
I’m working on a filesystem access library for SDL. Currently it
works
under Linux, but I haven’t enough time to support Win32 and other
versions. Would anybody like to help with the other ports? (Would
anybody even need such a library?)The library has no page right now, but I can set up a sourceforge
project if there is some interest in it.Have a nice day and lotsa sunshine,
Jiri “BlueBear” Dluhos (dluhosj at centrum dot cz)
Jiri Dluhos wrote:
Hello,
I’m working on a filesystem access library for SDL. Currently it works
under Linux, but I haven’t enough time to support Win32 and other
versions. Would anybody like to help with the other ports? (Would
^^^^^^^^
Umm, sorry, a typo.
I meant other platforms… you probably understood, but anyway…
Jiri Dluhos writes:
I’m working on a filesystem access library for SDL. Currently it works
under Linux, but I haven’t enough time to support Win32 and other
versions. Would anybody like to help with the other ports? (Would
anybody even need such a library?)
What do you foresee as the capability of the filesystem access
library? There’s already the <stdio.h> capabilities provided by most
if not all of the platforms currently running SDL. What would your
library contain beyond what stdio provides? Is there a reason not to
use stdio as the portable filesystem access library for this purpose?
Cheers,
Derrell
if not all of the platforms currently running SDL. What would your
library contain beyond what stdio provides? Is there a reason not to
use stdio as the portable filesystem access library for this purpose?
Presumably it mainly sorts out problems related to the lack of POSIX
functions such as opendir/readir/closedir under the Microsoft Windows
libraries?
-Thomas
stdio provides file IO functions, nothing else. A filesystem API would
provide directory access, pathname translation and other filesystem info
(such as free space).On Fri, Apr 13, 2001 at 10:18:27AM -0400, Derrell Lipman wrote:
Jiri Dluhos writes:
I’m working on a filesystem access library for SDL. Currently it works
under Linux, but I haven’t enough time to support Win32 and other
versions. Would anybody like to help with the other ports? (Would
anybody even need such a library?)What do you foresee as the capability of the filesystem access
library? There’s already the <stdio.h> capabilities provided by most
if not all of the platforms currently running SDL. What would your
library contain beyond what stdio provides? Is there a reason not to
use stdio as the portable filesystem access library for this purpose?
–
Martin
–
Bother, said Pooh, as the vice squad took his GIFS
I think he is more speeking of the location of standard directories, the
seperator signs for directories (/ on Ux and \ on DOS/Windows), the
file-device controlling (hda,hdb,etc… on UX or Linux, c:,d:,e:,etc… on
Win32) and maybe standard directories (e.g. /usr/lib and c:\WINNT\System,
C:\WINNT\System32). I think such things as an implementation (maybe with a
standardization for config files and maybe with a standard sdl .conf file
somewhere) could help making porting easier. Don’t know, what others think
about that, but I think espacially handling the places, where to put files
ca be something very confusing on different plattforms/os’s.
regards,
sascha
-----Ursprungliche Nachricht-----Von: owner-sdl at lokigames.com [mailto:owner-sdl at lokigames.com]Im Auftrag
von Derrell Lipman
Gesendet: Freitag, 13. April 2001 16:18
An: sdl at lokigames.com
Betreff: Re: [SDL] SDL_filesystem
Jiri Dluhos writes:
I’m working on a filesystem access library for SDL. Currently it works
under Linux, but I haven’t enough time to support Win32 and other
versions. Would anybody like to help with the other ports? (Would
anybody even need such a library?)
What do you foresee as the capability of the filesystem access
library? There’s already the <stdio.h> capabilities provided by most
if not all of the platforms currently running SDL. What would your
library contain beyond what stdio provides? Is there a reason not to
use stdio as the portable filesystem access library for this purpose?
Cheers,
Derrell
I agree… This would be a very useful general purpose lib.On Fri, 13 Apr 2001, you wrote:
Although useful for SDL developers, I suggest you don’t restrict your
audience to SDL developers.
–
Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >
[snip]
(Would anybody even need such a library?)
[snip]
Jiri,
I’ve been playing with different solution to
the exact problem space. Rather than focus on
reading and writing to a native filesystem,
I’ve begun to believe that the best approach is
to design an arbitrary resource archive format,
and associated library. It would provide basically
a virtual file system for the SDL programmer,
and avoid the whole sticky issue of installation.
I’d also like to just tie the binary into the
archive so that you can distribute one big file
that just works. Think of it as WAD files
meet Apple’s resources 
At work I write / maintain the system installation
software, so I've grown quite sick of even RPMs and DEBs,
and Microsoft's installation method scares the hell out
of me. And as most applications don't really share
files anyways, and given current ample RAM & HD space, and
that in 98% of cases shared libraries make little sense,
I'm of the growing opinion Linux would be a much more
viable platform, on the destop, if linux developers,
(especially game developers) just statically linked
more and managed their own filesystems ...On Fri, Apr 13, 2001 at 05:08:58AM -0700, Jiri Dluhos wrote:
–
david j. goehrig bit twiddler www.valinux.com
“There was nothing creative, charming, admirable or innovative in
Pok?mon except that it parted small children from their
money with brutal efficiency. It inexplicably featured the
dramatic story of cockfighting monsters who lived in your pants…”
- John Tynes
that just works. Think of it as WAD files
meet Apple’s resources
Sounds great! I agree that this would be a better solution to the
filesystem issue (if the reason most people want to muck with the file
system is to load program-related info and not just to crawl the user’s
drive)
of me. And as most applications don’t really share
files anyways, and given current ample RAM & HD space, and
that in 98% of cases shared libraries make little sense,
I’m of the growing opinion Linux would be a much more
viable platform, on the destop, if linux developers,
(especially game developers) just statically linked
more and managed their own filesystems …
Here here!! There is a use for dynamic libraries, but it’s on a largely
system level, and not on a userland level. Users should not be expected
to maintain ld paths, clear out their .dlls, and update their libs to
the most recent version.
Beyond general simplicity and the argument that most shared libs aren’t
being shared, there’s the installation issue (or more to the point, the
DEinstallation issue). How I long for the days where, to uninstall a
program, I deleted its directory!!
You wanna share? Use CORBA 
Hope the rant isn’t too off-topic (seeing as SDL uses a lot of libs ).
-Josh Emmons
“Josh Emmons” schrieb im Newsbeitrag news:Pine.BSO.4.10.10104131339220.24279-100000 at pchan.skycache.com…
that just works. Think of it as WAD files
meet Apple’s resourcesSounds great! I agree that this would be a better solution to the
filesystem issue (if the reason most people want to muck with the file
system is to load program-related info and not just to crawl the user’s
drive)of me. And as most applications don’t really share
files anyways, and given current ample RAM & HD space, and
that in 98% of cases shared libraries make little sense,
I’m of the growing opinion Linux would be a much more
viable platform, on the destop, if linux developers,
(especially game developers) just statically linked
more and managed their own filesystems …
That is what we need in C/C++ :=)
Look at this for FreePascal ( i used it some time ago ):
http://webs.demasiado.com:8080/freakpascal/zfs.htm
Zip File System
You create a ZIP File with all your data Files.
In your code you use ZFS_OpenZIP (FileName).
ZFS_OpenFile(FileName of a File in the ZIP)
uint8 ZFS_ReadByte()
ZFS_CloseFile()
And so on.> Here here!! There is a use for dynamic libraries, but it’s on a largely
system level, and not on a userland level. Users should not be expected
to maintain ld paths, clear out their .dlls, and update their libs to
the most recent version.Beyond general simplicity and the argument that most shared libs aren’t
being shared, there’s the installation issue (or more to the point, the
DEinstallation issue). How I long for the days where, to uninstall a
program, I deleted its directory!!You wanna share? Use CORBA
Hope the rant isn’t too off-topic (seeing as SDL uses a lot of libs
-Josh Emmons
Here here!! There is a use for dynamic libraries, but it’s on a
largely
system level, and not on a userland level. Users should not be
expected
to maintain ld paths, clear out their .dlls, and update their libs
to
the most recent version.
Beyond general simplicity and the argument that most shared libs
aren’t
being shared, there’s the installation issue (or more to the point,
the
DEinstallation issue). How I long for the days where, to uninstall
a
program, I deleted its directory!!
Olivier A. Dagenais - Software Architect and Developer
Supposing all that, how do you deal with LGPL software that should be
dynamically linked so that if the author(s) of an SDL program stop
maintaining the closed-source project, it is still possible to fix a
previously buggy library by dropping a new one in place of the old
one?
At Loki we distribute both statically linked and dynamically linked
binaries, and only provide support on the statically linked ones.
This allows people to use the dynamically linked code and upgrade
libraries, but allows us to support a known set of software. We
get the best of both worlds with only a few megs of extra install
footprint.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Thomas Harte <T.Harte at excite.com> schrieb am 13 Apr 2001:
Presumably it mainly sorts out problems related to the lack of POSIX
functions such as opendir/readir/closedir under the Microsoft Windows
libraries?
GLtron uses exactly these functions and runs under Microsoft Windows.
They might not be available in the standard VC++ headers, but they
certainly work for me. I’m cross-compiling with gcc, using Ray Kelm’s
excellent cross.sh setup http://from GCC Win32 Build Environment
Jiri Dluhos wrote:
Hello,
I’m working on a filesystem access library for SDL. Currently it works
under Linux, but I haven’t enough time to support Win32 and other
versions. Would anybody like to help with the other ports? (Would
anybody even need such a library?)
i’m was already working on such an library (but not SDL specific) for a
while.
~-n–
Enrico Weigelt
meTUX IT Services
www: www.metux.de
email: @Enrico_Weigelt
phone: +49 36207 51833
cellphone: +49 174 7066481
i’m was already working on such an library (but not SDL specific) for a
while.
Wow, are you working on a VFS library?
I keep forgetting. Please remind us all three or four more times.
–ryan.