Exactly. Such support essentially has to be integrated with the OS
itself, or it can't be used without causing more grief and confusion
than anything else.
Now, for the purpose of DJGPP programs, our libc already does
hide/emulate large parts of DOS/POSIX, respectively, so it could, in
principle, be extended to handle mount points, too. I don't think
that's a very good idea, though. The reason being that we don't have
a sufficiently "central" instance to handle this.
Cygwin tries to do something like this to simulate an even more
Unix-like environment on Win32 than DJGPP does on DOS. They do have a
'mount' command, whose settings survive reboots by being kept in the
Windows registry. This is used to provide a Unix-like single-root
tree, and mount the cygwin tool directory as both / and /usr.
They also have a "virtual drive" service that maps all paths of the
form "/cygdrive/d" to the drive letter "d:". It definitely has its
quirks (e.g. 'ls /cygdrive' will not show up empty, even though 'ls -d
/cygdrive/c' does show that at least one entry exists). But it works.
The big drawback is that this scheme *only* applies to those programs
built with the Cygwin DLLs, and that they tend to utterly confuse your
average Windows user.
I'm not all that sure about this. If a feature like Cygwin's were to
be added to DJGPP, then DJGPP.ENV would be the natural place to put
it. At the very least, DJGPP.ENV would have to hold the name of the
"/etc/mtab" equivalent file, which the libc code would then look into.
Hans-Bernhard Broeker ( XXXX@XXXXX.COM )
Even if all the snow were burnt, ashes would remain.