Re: [AD] Some more features for platform-independent file system?

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Wednesday 03 April 2002 02:45, Laurence Withers wrote:
> > which IMHO is beyond the scope of a
> > project such as Allegro.
>
> I don't think so. It is beyond the scope of Allegro to try and fix the
> broken dos filesystem (ie. if you swap two hard disks on your IDE
> interface, you'll probably end up reinstalling Windows, but it would be
> trivial to work this in Unix), but not to provide platform independence.
>
> The main idea of it is so that you don't need special handling for
> operating systems which don't have a single root directory. (We could
> also change it so that the operating system always supports the dos
> concept of 'drives', but this seems simpler). So if I want to
> write a fileselector, for example, I don't have to have an #ifdef
> ALLEGRO_DJGPP statement. My fileselector will work on every platform
> without modification, which is one of the main plus points of Allegro.

All true, but Allegro was designed to be a game library (though it 
certainly has other uses), and I don't think a filesystem API is a logical 
component of a game library. Also, Windows people who download a program 
made with Allegro may have a hard time figuring out why it works 
differently from what they're used to.
Code dealing with filesystems is probably the least portable of all - 
there aren't even portable low level functions to read a directory.

> > Furthermore, it can break in a pretty bad way: say I have a directory
> > (or even a file) called `c' in the root directory of my first drive,
> > then how should `/c' be interpreted? As c:/ or as c:/c?
>
> It would be called /c/c . Is this ever a problem though? Filenames will
> be generated either by Allegro (in which case they will be in our
> format), or by the operating system (in which case they will have a
> drive qualifier: c:\c ). In the latter case, we understand that x:\...
> means /x/...  (Please correct me if I'm wrong, though :-) ).

I was thinking more along the lines of the user typing /c as a filename, 
though if (s)he is a Windows user, it'd probably end up as \c instead.

> > DOS isn't UNIX, so don't pretend it is.
>
> I don't think anybody could pretend that :-)

Having installed bash and fileutils, I did get pretty far though - I even 
have /bin, /dev, /usr and /etc directories on my DOS partitition ;-)

> But this all comes about because it is very nice to write
> platform-independent code. As an aside, DJGPP actually does something
> similar to this: /dev/x/... refers to x:\... . 

Yeah, I remembered that too after I made my post. Never used it, though.

> > Also, I'm not quite sure what this would accomplish - it doesn't
> > improve portability because /c, if it existed at all, wouldn't have
> > the same meaning under UNIX as it would get under DOS.
>
> It just means we only have to worry about the concept of directories,
> and we can ignore the fact that 'drives' exist at all. It makes for
> simpler code (although of course we would continue to understand drive
> qualifiers, and keep the drive selector in the Allegro file selector,
> seeing as it is already written).

If we're going to have to understand them anyway, then wrapping things up 
differently as well is only going to make the code a lot more complicated.

[magically renaming .somefile files]
> > For one thing, with LFN enabled, .allegrorc is
> > a perfectly valid name even under DOS.
>
> Yes, true; however, try renaming a file to `.whatever' using Windows
> Explorer.

Ah. Ok, I never use Windows Explorer as a file manager, so I hadn't 
considered that. Does it behave well when opening such a file?

> [BTW Evert, I fully agree with the suggestion you made about the
> grabber using relative paths].

Thanks :-) I'll look into making this work in some way, since it's been 
bugging me for a while.

On Wednesday 03 April 2002 10:25, Lennart Steinke wrote:
> Why not use functions like:
>
> int  al_get_number_of_drives(); /* returns 1 on *nix */
> void al_get_drive_name(int no, char * name_buffer); /* name for drive 0
> on *nix would be / */
>
>
> void al_get_home_directory(int *buffer); /* $HOME on *nix, program dir
> on win */
>
> void al_get_virtual_root_dir(int *buffer); /* / on *nix, "My Computer"
> on win */

You can do that? Have to say I never tried, but specifying "My 
Computer/c:/Windows/notepad.exe" will actually work? Will it depend on the 
language of the Windows installed?

> This will allow you to write system independent file selection code
> easily.

I think this would be nice - and probably better than silently renaming 
files.

> I'm also not sure I like the idea of magically renaming files. I'd
> prefer to ask allegro for the propper name of a rc / ini file. Say like
> this:
>
> sprintf(filename, "%sallegro%s", al_get_ini_prefix(),
> al_get_ini_suffix());
>
> al_get_ini_prefix() would return "." on unix boxes "" on win boxes.
> al_get_ini_suffix() would return "rc" on unix boxes ".ini" on win boxes.
>
> You could alse write a wrapper function for the sprintf(), if needed.
>
> This allows the user to access all file systems the same way, use the
> same code to create "proper" ini files, and avoids problems since the
> native paths are untouched.

Agreed. I think this would be a nice way to handle it (though I don't 
particularly mind using #ifdef ALLEGRO_SOMESYSTEM myself).