unmount = mount -u driveletter

You can forget about the command.com without booting an image. (DosBox is primarily for games without having to worry about Microsoft Operating Systems....wasting time getting command.com working is not a DosBox goal (that doesn't mean support won't be added sometime in the future tho if somebody cares enough and if it doesn't affect normal DosBox operating)

The Windows 386 enhanced mode/mouse issue is known. I doubt the fix will be implemented time soon since it's supposed to affect DosBox speed. Doesn't the mouse work in Normal core using enhanced mode? It's been awhile since I bothered with Windows in DosBox since I use Quemu for that.

but I think it will evolve towards utility & Windows 3.xx emulator as well (people want it).

It may, it may not. DosBox goal is for games. Not for Utilities and Windows. It's hard to say wether DosBox will focus on those features in the future once game compatibility is 100% (heh..yeah right), or if someone will take the DosBox CVS and make their own project with Win 3.1/Win95 compatibility as a goal. I prefer DosBox as a game emulator because it's the best DOS game emulator in existance. Polluting it with unecessary code that will most likely affect DOS compatibility/speed is a bad idea IMO, especially when there is an excellent emulator like Qemu that emulates Windows 3.1 just fine.

>(...) excellent emulator like Qemu that emulates Windows 3.1 just fine

Excellent? Uh, I just tried it. Well, Norton Commander did not start and drive list in common file dialog Windows 3.1 was somewhat crippled. etc, etc.

overally, dosbox runs windows much better (though slower) IMO

I also have some suggestions:

1) I think imgmount should not exist, mount should do it all... it sounds more logical and consistent, not to mention easier for newbies... it would also work nicely once the physfs (for mounting zip files) is accepted as official. I'd put real consideration and serious thoughts on the final "mount-it-all" mount syntax; However, I think it can be done very elegantly. Mounting, from the users' point of view, is mounting, and the command should be the same no matter what you're mounting.

2) I think we should be able to mount to a specific directory, and not just drives; I'd like to be able to mount a directory, a zip file content, or even an image in a DOSBox folder and not just in the root of a drive.

3) I'd also suggest to be able to unmount *anything* but the Z drive (images, zip files, directories, anything and everything at any time… just for the sake of correctness) I'd also suggest using the umount command (if the number of programs in Z is the issue, think of having umount instead of imgmount) 😉

4) Little tiny command VER (I think it's pretty obvious what they should it do)

5) I suggest getting rid of the INTRO command; I'd put it as part of the HELP command instead.

6) Improve the commands help, and perhaps try to make the /? argument a standard for all commands, always giving good sober helpful, complete and updated information about the command and examples of it's use.

I think these suggestions, along some others in this thread, are good things to have, and I'm not even sure why they haven't been implemented... if the problem is the lack of time or programmers to do it, I'd be happy to help implement them (as busy as I am) because I honestly think these are missing features; however, I wouldn't want to spend valuable time programming them if at the end the changes won't be accepted as part of the main branch and left out to oblivion after a few months.

Please share your thoughts.
Kronuz.

I want to add a suggestion with has been made a few month ago on this forum I think:

Since DOSBox IS over all a game emulator, a SAVE Option would often come in VERY handy, not only for gaming purpose, but also to be able to benchmark a specific scene of a given game. I'm not that well of a programmer, but I think it shouldn't be too difficult to write the entire section of the RAM Dosbox resides in to a file (and for obvious reasons zip it). Especially for old games without inbound Save-System, this would be very nice.

I may have another suggestion, but at first I have to look up if it hasn't been already implemented 😉
I

> a SAVE Option would often come in VERY handy

Fine if YOU program THAT.

kronutz: If you can come up with a good syntax for a combined mount/imgmount
Try posting it here. It's seperated mainly to keep things more simple.

umount is only logical for people who are familiar with linux.

Qbix: I'll try to think of something for mount/imgmount, I'm sure it's possible to have a nice solution.

About umount, true... I agree umount is a unix word, but what about "unmount" I've seen tons of questions about an "unmount" which is obviously and intuitively the opposite of mount. I feel it's clearer to unmount something that has been mounted than to "mount –u" it 😉

Anyway, that, along with the "VER" command is just a minor suggestion, not entirely necessary.

Kronuz wrote:

I've seen tons of questions about an "unmount" which is obviously and intuitively the opposite of mount. I feel it's clearer to unmount something that has been mounted than to "mount –u" it 😉

Are the questions because the command isn't obvious enough, or are the questions because many ask before they read?

When I tried to unmount, my first try was umount. second unmount. third was readme.txt There I found "MOUNT -u "Emulated Drive letter"" and my question was answerred without asked first 😉

I think the problem is a file-read problem between keyboard and chair. By the way, I have the same fatal error sometimes as well, but it's not the app that's wrong 😎

My own opinion to create an alias is: don't. I dislike too many aliases since I always get confused by aliases. But that's my personal opinion.

A nice solution though could be an alias section in the dosbox.conf like this:

1[alias]
2umount=mount -u
3unmount=mount -u
4ls=dir

Well, make it configurable, some defaults perhaps, but so people can make their own aliases if they want.

No it's PBKAC. 😉

I prefer "Mount -u", but since we continue to get people who cannot read then including an "Unmount" command along with mount -u would be a good idea.

Although it's annoying to have 2 commands for the same function, It's not like we are eating up tons of code here.....and we can always remove "unmount" in the future.

I'd vote for the umount command. The -u option does not share much code with the rest of the mount command, so it could easily be factored out.
Merging mount and imgmount does seem a good idea to me too. There is a lot of code duplication between them.
Both would help to clean up the code and make it more maintainable.

If Kronuz hadn't already volunteered I'd would offer my help on it too, since I know that part of the code already.

cmw wrote:

Since DOSBox IS over all a game emulator, a SAVE Option would often come in VERY handy

This feature is asked about several times a week, and it has already been discussed at length and I think it was determined that it would take more work than anyone is prepared to spend on it at this time.

One of the big differences in requirements for state saving between DOSBox and most other emulators is that some DOS games store part of their state on the disk, so you'd have to somehow save and restore that data in addition to the contents of RAM (which can also be up to 64MB) and the state of the CPU/video/sound hardware.

Search the forum for some longer discussions about this.

prompt wrote:

I'd vote for the umount command. The -u option does not share much code with the rest of the mount command, so it could easily b […]
Show full quote

I'd vote for the umount command. The -u option does not share much code with the rest of the mount command, so it could easily be factored out.
Merging mount and imgmount does seem a good idea to me too. There is a lot of code duplication between them.
Both would help to clean up the code and make it more maintainable.

If Kronuz hadn't already volunteered I'd would offer my help on it too, since I know that part of the code already.

Sounds good, although unmount would be more intuitive than umount, unless maybe you're a Unix user 😉

HunterZ wrote:

prompt wrote:

I'd vote for the umount command. The -u option does not share much code with the rest of the mount command, so it could easily b […]
Show full quote

I'd vote for the umount command. The -u option does not share much code with the rest of the mount command, so it could easily be factored out.
Merging mount and imgmount does seem a good idea to me too. There is a lot of code duplication between them.
Both would help to clean up the code and make it more maintainable.

If Kronuz hadn't already volunteered I'd would offer my help on it too, since I know that part of the code already.

Sounds good, although unmount would be more intuitive than umount, unless maybe you're a Unix user 😉

Won't people all be *nix users eventually? 😉 Ubuntu is pretty darn easy, even my folks can use it...

Anyway, I vote for the standard mount and umount.

I think imgmount doesn't get enough attention. A lot of people seem to think daemon tools or something is needed to mount isos...
DOSBox has iso support built in, and only info regarding mount is provided with INTRO...

Barring that, maybe provide info about imgmount in INTRO.

What do you guys/gals think?

QuietGuy wrote:

Are the questions because the command isn't obvious enough, or are the questions because many ask before they read? […]
Show full quote

Kronuz wrote:

I've seen tons of questions about an "unmount" which is obviously and intuitively the opposite of mount. I feel it's clearer to unmount something that has been mounted than to "mount –u" it 😉

Are the questions because the command isn't obvious enough, or are the questions because many ask before they read?

When I tried to unmount, my first try was umount. second unmount. third was readme.txt There I found "MOUNT -u "Emulated Drive letter"" and my question was answerred without asked first 😉

I think the problem is a file-read problem between keyboard and chair. By the way, I have the same fatal error sometimes as well, but it's not the app that's wrong 😎

My own opinion to create an alias is: don't. I dislike too many aliases since I always get confused by aliases. But that's my personal opinion.

A nice solution though could be an alias section in the dosbox.conf like this:

Copy code to clipboard

1[alias]
2umount=mount -u
3unmount=mount -u
4ls=dir

Well, make it configurable, some defaults perhaps, but so people can make their own aliases if they want.

Brilliant! If I had a dollar for every time I've typed ls in DOSBox, well I'd have like 15 bucks...

I am very glad it does handle / though. So even if something is "C:\EPIC\TYRIAN" I can still do a cd EPIC/TYRIAN

I suggested "ls" a long time ago. It was determined that DosBox is a "DOS" emulator. Not a linux emulator so "ls" was shot down. There's nothing preventing something from adding it themselves though or creating an unofficial patch to implement the functionality.

Also I too still type "ls" way too often in DosBox. 😀

Of course the DosBox devs have been known to break down on some things so perhaps ls functionality could be included.....but I think it won't happen.

aliases. Well people can add their own if they recompile the source. Adding something like "ls" is 1 line in src/shell/shell_cmds.cpp

Kronutz I read you were on the irc channel as well about the mount/imgmount functionality.

I would really first like to see the syntax you have in mind BEFORE you start coding on it.

Qbix wrote:

aliases. Well people can add their own if they recompile the source. Adding something like "ls" is 1 line in src/shell/shell_cmds.cpp

But not every user has enough knowledge to recompile the source. Besides, if a new version is released, or someone wants to try a new cvs-version, he has to edit shell_cmds.cpp again. That's why I suggested an alias part.

By the way, for those who type "ls" a lot, make a batchfile with @dir %1 %2 %3 %4 or something, works as well 😜

Doesn't sound like the most important thing one has to worry about.