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

[Laurence Withers <lwithers@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 03 April 2002 00:18 am, Evert Glebbeek wrote:

[snip - pretend dos drives are in the root directory]
> I must say I don't really like this - what it does basically is
> transform the DOS/Windows filesystem to a UNIX like filesystem (which
> is a good thing in many ways),

Yes, the Unix-model filesystem makes a good deal of sense.

> 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.

> 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 :-) ).

> DOS isn't UNIX, so don't pretend it is.

I don't think anybody could pretend that :-)
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:\... . However, this method 
does mean that a directory called 'dev' will cause problems (and a 
surprising number of people install DJGPP in c:\dev ).

> 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).

> I like this idea. I currently use some platform dependent code to
> grab the $HOME variable under Linux.

Yes, getenv("HOME") is nearly enough, but not quite. It will work OK on 
my DJGPP system, but I doubt that many people set it to something 
sensible (or even anything at all).

> 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.

> Secondly, calling the config
> file allegrorc under UNIX makes sense since that is the convention.
> It doesn't make sense under Windows, where the convention would be
> that it's called allegro.ini.

Very true, but again the idea is to remove platform-dependent code. It 
makes sense to precede the filename with a fullstop under Unix, because 
it makes the file hidden, but it doesn't on dos (although it probably 
wouldn't do any harm if lfn is enabled).

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

Bye for now,
- -- 
Laurence Withers, lwithers@xxxxxxxxxx
                 http://www.lwithers.demon.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8qlC3ZutPpDHGwY0RAgHwAJ9eJU2y7sl+15NibaUyD8XqSxv8fwCgz+uH
Es+T1hcn2h0vmzVuWu2IScM=
=g+e5
-----END PGP SIGNATURE-----