Anyway, I don't like the idea of dealing with actual folders. When I mount my ~/.DOS folder as drive C. I already have access to the folders within there. Why add the level of confusion with real system folders. This would get annoying fast...

Does dosbox handle mounted zips?

Also, why no umount?

Other than that, I'm all for removing imgmount as noted in my other post...

New features/fixes suggested! (floppy imgmount and more)

It doesn't get much love in INTRO, and many people don't use it (they think they daemon tools or something)

boyofdestiny wrote:

Anyway, I don't like the idea of dealing with actual folders. When I mount my ~/.DOS folder as drive C. I already have access to the folders within there. Why add the level of confusion with real system folders. This would get annoying fast...

I think you missed the point of "real directories", if that's what you meant by actual folders. Right now, you can't mount stuff that it's already mounted in DOSBox, such as a folder that's already mounted. The bad thing about this comes with the mounting of images and zip files... if we keep the current scheme, we have no way of telling mount whether the image or zip to be mounted is a file in a DOSBox folder (a "virtual" file mounted as part of the filesystem of a mounted drive somewhere inside DOSBox) or a real file living in the real physical filesystem (not inside DOSBox); thus, we can't unequivocally refer to a file in the whole system without the uncertainty of having an ambiguity.

To show just an example: in a DOSBox command, 'C:\image.iso'refers to the real file in the hard drive's root directory, or to the "virtual" file mounted in the C: drive in DOSBox, which could actually be in the real physical location 'D:\DOSBox\images\image.iso'?

According to the DOSBox README, the command IMGMOUNT takes and imagefile that "is on a mounted drive inside DOSBox"; however, it also says: "CD-ROM images can be mounted directly as well. They don't have to be on a mounted drive." This is just too vague to be acceptable in every situation.

What if you have the two files in the real filesystem: 'D:\DOSBox\images\image.iso' and also 'C:\image.iso'. To which one would the command 'mount d C:\image.iso', in DOSBox, be referring to? To the one in 'D:\DOSBox\images\image.iso', mounted by a previous 'mount c D:\DOSBox\images' command call or to the real 'C:\image.iso' outside DOSBox and in the real root directory of the physical C: drive?

This is why I'm suggesting a way to differentiate between "DOSBox folders and files" (or local folders and files) and the "real physical directories and files" (or the real directories and files.)

In my opinion, having IMGMOUNT (or any other mount command) able to mount something inside of an already-mounted filesystem is just weird and needlessly complicated. Mount/Imgmount should always point to paths/files in the real filesystem.

Also, it might be more friendly to make it so that attempting to mount something to a location that already has something mounted to it (e.g. mount c d:\oldgames followed by mount c d:\newgames) would cause the DOSBox to terminate the old mount and create the new one. Currently (I think) it issues an error message instead.

The location of the image file needing to be in a mounted folder doesn't seem right to me as well. Also, I like your idea of mounting a new drive with an existing drive's letter unmounting the old drive automatically.

I know that the idea of the simple GUI of the addition of a menu bar to the DOSBox window has been brought up before, but it might be nice to have a way to mount and unmount on the fly, even if you don't have access to DOSBox's command prompt at the time, like when you are in the middle of running a program or game. It would be nice to be able to do it without using up more hot keys.

I originally created the separate "imgmount" command to keep the stable and properly working "mount" command from being affected by any of my dumb ideas. I think at this point, however, the "imgmount" functionality and syntax are fairly consistent and stable. I agree with the apparentl majority opinion... imgmount needs to merge with mount.

I agree with the idea that some of the commands inside dosbox need to be updated, but I also think that they need to be simpler than before and no more complex.
Merging mount and imgmount is a good idea, adding more parameters to mount is not so good.
Moreover I believe that all dosbox internal commands need to have few, powerful, intuitive parameters and in presence of missing parameters dosbox should always try to automatically compensate whenever is possible.

- It could be that (sooner or later) image cycling is going to be implemented, there should be a way to specify this.
- Unmounting and setting ide channels should be separated commands, in my opinion, since this is different functionality. (And you have less special cases when implementing the mount command.)
- Mounting from dosbox drives is useful for images.

the ! will break all corrent created dosbox.confs.
umounting doesn't need to be a seperate command imo as it't barely used.

kekko wrote:

I also think that they need to be simpler than before and no more complex.
Merging mount and imgmount is a good idea, adding more parameters to mount is not so good.

Unfortunately, accomplishing both goals it's hard to do, this is why we are trying to come up with a good simple usable but yet powerful new syntax for the mount command; however, if you check the new syntax, aside from adding that new "weird" concept of differentiating between real paths and the DOSBox "virtual" paths, the new mount command actually makes things simpler than any of the two current commands and most of the options are, as it's name says so, really optional, thus you can use the new mount syntax more easily, and effectively make current commands simpler, while still having powerful "advanced" options. Perhaps the issue here would be to write several sub-syntaxes along with more examples and the more general super-syntax I've already written; just to make it easy for newbies and so they don't get lost in the power of the command.

Now, back to the weirdness of the '!' prefix, Qbix, if that symbol would break the dosbox.conf in some way, we can use another symbol; if the symbol is not the problem, but the concept, I guess we could leave that feature out, and just make the mount command always refer to real directories and files. Though I'd really like to be able to mount image files that are mounted in a DOSBox folder (such as images inside zipped files, for instance... to which you can't access directly using a real path.)

About the unmount as a separated command, I partially agree with Qbix, it doesn't need to be a separated command; nonetheless, I disagree on the generalization. I constantly and actively use the unmounting feature; in fact, to be honest, I like to be able to run many games and apps, and not just one per DOSBox session, hence my strong devotion toward the stability and consistency of the unmounting features (specially for CD images.)

I'm glad to be receiving all this critiques. I also hope we get more suggestions on how to improve the syntax.

Apropos '!': Why not keep it as it is: First search for the file on a dosbox drive, and if not found search on the host system?

prompt: Yes, that's other option too, I guess the ambiguity would not be that bad... I mean how often would someone have two files with the same name: one real file and one virtual file mounted in DOSBox in the same path (real and virtual) but different content 😜

prompt wrote:

Apropos '!': Why not keep it as it is: First search for the file on a dosbox drive, and if not found search on the host system?

Yes. And maybe ! and some other character could be used to specify that it is *only a real path* or *only a path on DOSBOX drive* (not compulsory, the default behaviour would be as prompt proposed)...
In this way nothing existing would be broken, but if somebody needed more precise specification for whatever reason he could use it...

Mirek

Kronuz wrote:

I think you missed the point of "real directories", if that's what you meant by actual folders. Right now, you can't mount stuff […]
Show full quote

boyofdestiny wrote:

Anyway, I don't like the idea of dealing with actual folders. When I mount my ~/.DOS folder as drive C. I already have access to the folders within there. Why add the level of confusion with real system folders. This would get annoying fast...

I think you missed the point of "real directories", if that's what you meant by actual folders. Right now, you can't mount stuff that it's already mounted in DOSBox, such as a folder that's already mounted. The bad thing about this comes with the mounting of images and zip files... if we keep the current scheme, we have no way of telling mount whether the image or zip to be mounted is a file in a DOSBox folder (a "virtual" file mounted as part of the filesystem of a mounted drive somewhere inside DOSBox) or a real file living in the real physical filesystem (not inside DOSBox); thus, we can't unequivocally refer to a file in the whole system without the uncertainty of having an ambiguity.

To show just an example: in a DOSBox command, 'C:\image.iso'refers to the real file in the hard drive's root directory, or to the "virtual" file mounted in the C: drive in DOSBox, which could actually be in the real physical location 'D:\DOSBox\images\image.iso'?

According to the DOSBox README, the command IMGMOUNT takes and imagefile that "is on a mounted drive inside DOSBox"; however, it also says: "CD-ROM images can be mounted directly as well. They don't have to be on a mounted drive." This is just too vague to be acceptable in every situation.

What if you have the two files in the real filesystem: 'D:\DOSBox\images\image.iso' and also 'C:\image.iso'. To which one would the command 'mount d C:\image.iso', in DOSBox, be referring to? To the one in 'D:\DOSBox\images\image.iso', mounted by a previous 'mount c D:\DOSBox\images' command call or to the real 'C:\image.iso' outside DOSBox and in the real root directory of the physical C: drive?

This is why I'm suggesting a way to differentiate between "DOSBox folders and files" (or local folders and files) and the "real physical directories and files" (or the real directories and files.)

Yes, I use folder and directory interchangeably. They are just levels of abstraction anyway.

In the case of Linux (and mac I'd guess) It isn't a question of C:\image.iso or the real folder C:\DOSBox\blah\blah. I have no C:\ to worry about it. All my personal stuff is in ~/.
So /home/username/DOSfolder/stuff is pretty clear it's not C:\stuff.

So there is nothing to be confused about, which is probably why I missed the point... 😀

So I guess this could be a workaround:
Ensure ISO's you want to mount as CD's are located in the "drive" dosbox mounts.

The benefit of doing this is that people can move his/her .DOS folder to any Linux box (even windows boxes or mac boxes), mount it, and it would work (in my case it would have to be mounted as c)

P.S. prompt, I wouldn't want DOSBox to try and poke around the host filesystem for a file that it doesn't find. People makes typos too, and just seems like a way to make things insecure... Just my opinion...

boyofdestiny wrote:

In the case of Linux (and mac I'd guess) It isn't a question of C:\image.iso or the real folder C:\DOSBox\blah\blah. I have no C:\ to worry about it. All my personal stuff is in ~/.
So /home/username/DOSfolder/stuff is pretty clear it's not C:\stuff.

Right, in *nix environments this couldn't get confused as easily. But hey, having a way of mounting file images located in a mounted drive inside DOSBox is not a useless feature, and at least for windows (and for the sake of consistency) we should come up with some way of specifying whether it refers to a path mounted in DOSBox drive or to a real path outside DOSBox.

Anyway, what do you think about the other parts of the syntax?

to continue on the ! thing. I think reversing their usage would be more consistent with the current mount. (so ! for mounting stuff that is inside dosbox) and perharps doing the double check on both systems although a mount c c:\ wouldn't be that great for that.

the <channel|drive[:[directory]]> looks weird to be honest. It's very confusing. If I read that part I don't have a clue what is meant by that.

Kronuz wrote:

Right, in *nix environments this couldn't get confused as easily. But hey, having a way of mounting file images located in a mounted drive inside DOSBox is not a useless feature, and at least for windows (and for the sake of consistency) we should come up with some way of specifying whether it refers to a path mounted in DOSBox drive or to a real path outside DOSBox.

Anyway, what do you think about the other parts of the syntax?

Well it seems ok (the examples are clear, I always have trouble just looking at the manual...)

The only thing I don't like is the ! thing (I always read it as NOT or an exclaimation... or factorial I guess...) I'd prefer something like

host:C:\DOS\
to differentiate from mounted C:\ stuff

Seems easy, and shouldn't break unless somone has a drive called host:, which should be impossible/unlikely I think...