MOUNT.EXE

MOUNT.EXE

Post by sebastie » Tue, 23 Sep 2003 18:11:48


hello,

i've seen MKISOFS/CDRTOOLS for MS-DOS but i think i must use
MOUNT.EXE, it is available for MS-DOS ?
 
 
 

MOUNT.EXE

Post by Hans-Bernh » Tue, 23 Sep 2003 19:25:00


Why do you think so?


No... the whole idea behind mount doesn't exist in MS-DOS.
--
Hans-Bernhard Broeker ( XXXX@XXXXX.COM )
Even if all the snow were burnt, ashes would remain.

 
 
 

MOUNT.EXE

Post by bdec » Wed, 24 Sep 2003 20:00:09


Very interesting... I have always wondered what it would take to make the
virtual directory table on DJGPP ("i.e. /dev/env/DJDIR, /dev/d, /dev/c,
/dev/com1, etc...) extensible. Perhaps a mock 'mount' and 'umount'
executable could add additional devices and physical directories (even
commands) to the DJGPP.ENV....

Just an idea...

Ben
 
 
 

MOUNT.EXE

Post by Hans-Bernh » Wed, 24 Sep 2003 21:12:36


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.
 
 
 

MOUNT.EXE

Post by Eli Zarets » Wed, 24 Sep 2003 21:29:26

> From: "bdeck" < XXXX@XXXXX.COM >

They _are_ extensible; see the node "File System Extensions" in the
DJGPP library's reference docs.

However, such extensions are private to the program that uses them.
You cannot easily have a program like `mount' mount some pseudo-device
and have that device visible in another program, unless you leave
some record to that effect on disk or something.


It would be a very bad idea IMHO to rewrite DJGPP.ENV to support this
kind of feature. It's better to record the info on some other file.
 
 
 

MOUNT.EXE

Post by bdec » Thu, 25 Sep 2003 00:22:14


Very true, but "/dev/env/DJDIR" is anyway DJGPP specific (as well as any
/dev device hardcoded into applications), so I think it is pretty hard to
say that we are completely free of that confusion ;-) I think it would make
a nice feature, though, for advanced users. Like I said, it was just an
idea.



I thought of that, too. I guess it is a pro-and-con issue of how many system
files you want floating around in the end ;-) but I think it would be
logical to define all mounts in one file, and DJDIR is more or less a mount.





So I guess all that is missing is the interface to exactly such a textfile
;-)


Regards,
Ben