remove DOSDRIVE_D and drive_z?

[stsp]

I've finally got to review our installation and boot process, which, as always, means a big axe. I am puzzled about DOSDRIVE_D, lredir to Z: and mounting /home/$USER to D: by default. I don't know why these 3 steps are there, so I want to get them removed.

Bart, you added it, could you please explain a bit of rationale? Is this Z: trick useful, and is DOSDRIVE_D used by anyone? Does mounting /home/$USER to D: make any sense?

[stsp]

@bartoldeman are you subscribed? Please click "Watch" button on this tracker already. :)

[bartoldeman]

Long story. A long time ago with dosemu 1.0 "-home" was optional and if it was set it would mount the home directory to drive D. At some point (1.1.4.12) -home was made the default. This made it easier to explain the default setup in the readme (see http://dosemu.sourceforge.net/docs/README/1.4/t1.html#AEN14)

DOSDRIVE_D simply allows you to override to use something else instead of $HOME for D: without needing to edit any files.

I like having my home directory accessible from dosemu as all my files are there -- if it were removed I would just put the lredir back in autoexec.bat.

For C: and Z: -- I needed a mechanism so that FreeDOS and DOSEMU commands could be upgraded centrally by make install (in e.g /usr/local/share/dosemu/drive_z), but that means that those files need to be read/only for normal users. On the other hand we need an r/w C drive so that users can edit their own autoexec.bat and config.sys, and have a temp directory. If you want to get rid of Z: you need to instead use symlinks from C: (or something else you can think of), which means that some directories on C: are read/only; now we have Z: r/o and C: r/w and I find that easier to remember.

Of course before there were setups with real FAT16/FAT32 C partitions and emusys but very few people have those anymore, ever since Windows XP and NTFS as its default FS. Although IIRC you yourself are using emusys? With a real FAT partition?

[stsp]

I like having my home directory accessible from dosemu as all my files are there -- if it were removed I would just put the lredir back in autoexec.bat.

Can you just update your $_hdimage setting instead? IMHO every user should tweak his "drives" setup by just adjusting $_hdimage. Mounting home by default, looks exceptionally specific to your own needs.

DOSDRIVE_D simply allows you to override to use something else instead of $HOME for D: without needing to edit any files.

How about EXTRA_DOSDRIVE var that will use the next available drive, instead of D? It could even use path separators to allocate multiple drives. While the functionality is good, I am not satisfied with that dancing of mapping and unmapping D: to suit for both freedos and DOSDRIVE_D.

autoexec.bat and config.sys, and have a temp directory. If you want to get rid of Z: you need to instead use symlinks from C: (or something else you can think of), which means that some directories on C: are read/only; now we have Z: r/o and C: r/w and I find that easier to remember.

I am not sure I follow the logic here. drive_z is initially mapped to D, not C. And it is mostly a freedos. If I remove drive_z, then C will remain r/w but D will become r/o (instead of Z), and for that reason I also want to remove DOSDRIVE_D.

Of course before there were setups with real FAT16/FAT32 C partitions and emusys but very few people have those anymore, ever since Windows XP and NTFS as its default FS. Although IIRC you yourself are using emusys? With a real FAT partition?

Yes, I still use that setup. But as the freedos installing became a contentious topic, I have started looking into this one too. I really want to come up with something simple here. It would be nice if you look into the changes I already made, to make sure they do not break your use-cases.

[bartoldeman]

the default drives/* setup allows running dosemu without any .dosemurc installed, purely using the defaults. That's why I borrowed the approach from Wine: https://www.winehq.org/docs/wineusr-guide/config-wine-main as for D vs Z, in the end if you go back to the drawing table it does not matter. Z is familiar to dosbox users obviously but it needs some tricks as you noticed as it is not available in the early stages booting dos.

Then it becomes only about backwards compatibility -- there will be users used to having D: = $HOME, and they'll have to edit autoexec.bat or fixup things. Some tutorials would also be out of date, e.g. https://awarewriter.wordpress.com/2014/03/17/maxthink-running-the-dos-version-in-linux/ https://ugotsta.wordpress.com/2015/07/14/qbasic-through-dosemu-in-cool-retro-term/

I am quite busy the rest of this week so may be slow replying later...

[stsp]

the default drives/* setup allows running dosemu without any .dosemurc installed, purely using the defaults. That's why I borrowed the approach from Wine:

Does wine also include the home directory? Seems not. So its not the same setup after all.

Some tutorials would also be out of date, e.g.

Thanks for the pointers. Well, its exceptionally pity they used this. More so because they used home simply as a "shared point" between DOS and the host file system (to transfer files), but that could instead be /tmp/dosemu or just ~/.dosemu/drives/c/tmp or whatever, but not home! :( My home dir has lots of files, most not fitting the 8.3 naming format. This makes drive D: a complete trash can in any file manager (that do not support LFNs at least), of course not mentioning the fact that all those files have absolutely zero relevance to dos or dosemu. So while I admit the compatibility concerns here, I'd like to have some compromise, maybe just to undefault back "-home"... Oh crap. :)

Lets hope at least DOSDRIVE_D was never used, so I'll remove this and likely will add EXTRA_DOSDRIVE as a replacement.

[kalpha2]

Wine's winecfg has a drives tab with an Autodetect button which does add the home directory. I'm not sure but I think I may have used some distro packages in past where the home dir was already mapped.

[stsp]

Wine's winecfg has a drives tab with an Autodetect button which does add the home directory.

What is the expected usage of it under wine?

[kalpha2]

erm ... use windows apps on data in your home directory e.g. office docs, pictures, etc.... sometimes it's easier/quicker to use tools you are used to either while you are still trying to master alternatives or are of a certain age that you need the comfort of old tools while blissfully ignorant your son has you using a totally different OS that you used to be on......

[stsp]

Yes, I can imagine such a use. You got word document by e-mail and open it with ms-word under wine. But with dosemu, the only use I've seen is to access the files downloaded from internet. There are no dos progs or anything the dos progs could use, in your home dir.

[kalpha2]

erm2... I have some clients running dos software under dosemu storing their local data in home (sub) folders. Some are running under X and via the UNIX cmd in dosemu invoke linux apps and e.g. create a pdf and then invoke a viewer. Some others have no X and cron and incron jobs then run linux scripts and code on some of that data that has come from the dos apps running under dosemu....

[stsp]

erm2... I have some clients running dos software under dosemu storing their local data in home (sub) folders.

Yes, and that sub-folder should be ~/.dosemu/drives/... The only reason I can see for exporting entire home, is when you have the sufficient amount of linux progs (esp GUI progs) with which you can work on some data, with which you can also work under DOS. This is clearly the case with wine, as under wine you can work with many things created by linux desktop apps. But if you have only some linux script that works with some DOS data, you certainly don't need the entire home dir.

[kalpha2]

thats one way to look at ... personally I prefer DATA to be not under hidden wine or dosemu folders but in DATA related folder. Also there are some that toggle between DosEmu and DosBox..... and as per my other request I'd like to be able to parallel run stable and dev versions of DosEmu (which may / should have different "OS" based locations for internal commands and config) but be able to interact with same DATA data...

[stsp]

You could have non-hidden folder, like ~/dosemu or ~/dosdata. Exporting entire home is absolutely insane for just a very small data exchange.

[stsp]

Or please give me examples of your many apps that store their data in their respective dirs under home (please create the app_name:home_dir list to see it visually), which you want to access from dosemu. For wine such a list can easily be created. But your single linux script doesn't have a dedicated dir under home, so that one doesn't count.

[stsp]

Also there are some that toggle between DosEmu and DosBox.....

Does dosbox already mount your home on startup by default?

[bartoldeman]

Insane is just what you think. Sure you expose a lot more than necessary but it is convenient for me to say install doom in $HOME/doom fire up dosemu, do "d:" "cd doom" and you're there. I also had source code files (e.g. FreeDOS kernel) that I would sometimes compile inside dosemu and sometimes cross-compile in Linux.

If you compare to other solutions:

NTVDM -- this does the equivalent of "lredir d: linux\fs/", exposing ALL drives and all files to it. Having that in dosemu is posssible but annoying because you need to "d:" "cd /home/username/doom" instead. By your definition NTVDM is then completely insane :)

dosbox -- by default does nothing. I type "intro", and it will tell me to use for example "mount c ~/dosgames". This is closer to what you want.

[stsp]

Insane is just what you think.

Yes, I look into the content of my D drive - thousands of long-named files that look like a crap under DOS - and think this is very much insane.

Sure you expose a lot more than necessary but it is convenient for me to say install doom in $HOME/doom

How? Do you have a linux installer for DOS doom?

I also had source code files (e.g. FreeDOS kernel) that I would sometimes compile inside dosemu and sometimes cross-compile in Linux.

How does this all not work with ~/dosemu? (~/dosemu/freedos etc) The point is that, while you compile freedos under linux, you never use it under linux, so its particular location under linux doesn't matter. This is in contrast with wine, where you work on documents that OpenOffice puts to your ~/Documents, so having home there makes sense.

By your definition NTVDM is then completely insane :)

ntvdm came from the DOS era, and have already died. So MS also thought this is insane, and removed it. In times of WinNT 3.51, many progs had a mixture of dos and windows executables, plus the ability to execute DOS files under windows, and windows files from DOS prompt was important. Today this is hardly so, and no ntvdm as the result.

dosbox -- by default does nothing. I type "intro", and it will tell me to use for example "mount c ~/dosgames". This is closer to what you want.

Should I switch to dosbox? :)

[stsp]

I think ntvdm was never meant to be a full-featured emulator. This was mostly for the seamless integration of the console DOS apps into windows environment, so that you can eg run dos-based borland compilers to compile win32 program and run it from DOS prompt, access windows clipboard from DOS apps, etc. You could hardly run any game with it (except for its windows-xp versions, where it started to barely support sound, and a couple of games could work).

[stsp]

In any case, I wasn't going to remove the "-home" option: if people think they need it (which is obviously not true, but we have a freedom of thinking), the "-home" should just be there. So what is a big deal? Correction: no boot delays I mentioned above, as home is mapped from autoexec.

[stsp]

NTVDM -- this does the equivalent of "lredir d: linux\fs/", exposing ALL drives and all files to it.

Actually, this is/was not correct. When ntvdm appeared, IIRC the windows directory structure was compatible with the one of DOS. You would have a couple of directories on every drive's root, no LFNs, dos binaries everywhere, together with the win32 ones. It was basically a familiar DOS structure (I mean NT3.51), and most importantly, some of the drives were the plain DOS drives from dual-boot. Running ntvdm on today's windows is impossible since it is not there. But be it still there - yes, that would make no sense at all to export "My Computer" to DOS. But please don't compare something that doesn't exist and isn't possible to something that really works, as such comparison is unfair.

[bolle732]

I use productivity software under DOSemu and have some folders under the $HOME and /media mapped to specific DOS drives. Never used the "-home" option. Always using a program specific "dosemu.conf" with the specific configuration. As long as I can map drives to any folder by the help of "dosemu.conf", I doesn't bother.

[stsp]

I use productivity software under DOSemu and have some folders under the $HOME and /media

Is this some specific dir under $HOME, or just any, for the file exchange?

mapped to specific DOS drives. Never used the "-home" option.

You couldn't, it was made a default at some point! Be it just an option, there would be no big deal, but promoting it to default is completely unacceptable.

[stsp]

"dosemu.conf" with the specific configuration. As long as I can map drives to any folder by the help of "dosemu.conf", I doesn't bother.

There is unfortunately still the need for an alternative way of setting up drives, because $_hdimage only sets up drives via fatfs, while DOSDRIVE_D/-home works via autoexec, which avoids the fatfs boot slowdown. So I'd like to provide a replacement for DOSDRIVE_D, but I can't decide what should it be. EXTRA_DOSDRIVE env? Some new command-line option? New dosemu.conf option?

[bolle732]

Depending on the DOS program, I map a specific folder under $HOME for it with the help of an entry in the variable $_hdimage in its corresponding copy of dosemu.conf. My autoexec.bat here doesn't contain any lredir entries for the magic about D: and Z:. All DOS related files are in there own drive_c folder for the DOS program. I run only a handful DOS programs and managing the different drive_c folders haven't been a nightmare.

As I don't run single DOS commands from shell scripts, the speed doesn't hurt me.

Only my 2 cents (or 1 and a half): As far as I can see, it looks to me that we should distinguish between local copy of DOS files from the user with RW access (like me) and central DOS files of the system with RO access (like normal DOSEmu users). In the first case with RW, we don't need any magic. In the later case where users have only RO, there should be some way to overdrive files to accomplish i.e. other settings from config.sys/autoexec.bat. As I understand, this is the magic of drive_z already exiting.

I tried to start writing about some ideas, but it growed rapidly into a large story. At the end, it will come together with the other issue about installing FreeDOS https://github.com/stsp/dosemu2/issues/93. How far should it go ? Only one central DOS installation with the possibility to customize the behaviour for different DOS programs ? A management tool for different central DOS installations with the possibility to checkout a customized copy into a local folder of the user for a specific DOS program and maybe with the possibility to update this local folder from updates of the central one ? There must be someone with a lot of spare time...

Back to the DOSDRIVE_D, I would let the people speak for it, who use it. As long as I can specify my data exchange folders in $_hdimage and they can get the D: too, I'm happy.

[stsp]

Depending on the DOS program, I map a specific folder under $HOME for it with the help of an entry in the variable $_hdimage in its corresponding copy of dosemu.conf.

The question is more, whether you are forced to use the particular dir in $HOME because some linux software uses exactly it, so you can't move. Or you choose it yourself, in which case it can be something like ~/dosemu/*. People here so far only showed the examples of an arbitrary choices made by themselves. This doesn't count as an argument for making -home a default - this is just a personal preference, so should be optional.

the DOS program. I run only a handful DOS programs and managing the different drive_c folders haven't been a nightmare.

Note that you can do: dosemu -K /linux/path/to/dos/prog.exe in which case it will dynamically create the DOS drive for that prog and will run it from there on "system -e". This may be the even more convenient way for you.

I tried to start writing about some ideas, but it growed rapidly into a large story. At the end, it will come together with the other issue about installing FreeDOS #93. How far should it go ? Only one central DOS installation with the possibility to customize the behaviour for different DOS programs ?

No final decision yet, but IMHO it should be 1 or 0 central installations (in case of 0 you install from internet), and a script that can update from that 1 or internet. Update, in a simple case, just includes purge+install, so it shouldn't be too hard.

[bolle732]

Thank you for the "dosemu -K " hint. In my case, I prefer a static setup. As said, let the people decide who need or use this behaviour.

[stsp]

Thank you for the "dosemu -K " hint. In my case, I prefer a static setup.

-K is a static setup, as it allows to not change the configuration for every new program. Your setup doesn't looks static, hence was the suggestion.

[jschwartzenberg]

I never understood either why there were so many special tricks. I'd expect a symlink in ~/.dosemu/drives to point to my homedir.

I thought one issue was that it was not entirely predictable which directory/symlink would be mapped to which drive, as it depends on the alphabetical order. Maybe doing it the Wine way (~/.wine/dosdevices/c: always becoming c:, etc.) would make it more simple.

[stsp]

I never understood either why there were so many special tricks. I'd expect a symlink in ~/.dosemu/drives to point to my homedir.

Too slow and is limited to the capacity of a fatfs partition. Plus inflexible, as you then can't disable this with any options at all. Yes, currently it is also not disableable for some very odd reason, but it won't last for too long.

which drive, as it depends on the alphabetical order. Maybe doing it the Wine way (~/.wine /dosdevices/c: always becoming c:, etc.) would make it more simple.

We already do the same, unless you populate the ~/.dosemu/drives/ with some symlinks by hands, which is not what you normally should do, or if you use DOSDRIVE_D which is a discrepancy that will be removed.

[jschwartzenberg]

Too slow, you mean performance wise? It's quicker to put symlinks in there than to add emufs/lredir lines, so that's what I've always been doing. Would it be possible to solve the performance issue if it'd really that big of a difference?

[stsp]

You shouldn't put symlinks, and you shouldn't put lredir. The directory has a starting dot for a reason: users don't mess with the dotted dirs. All you should do is to alter $_hdimage. If this is not flexible enough, we can add:

• ~/dosemu (without a dot) as an extra drive
• DOSDRIVE_EXTRA var to allocate yet more drives

The performance problem is unsolvable with the symlinks approach (that's why I strongly advice against adding them by hands; the dir is dotted for a reason), and the actual slowdown depends on how many dirs you have at your $HOME. Also if it exceeds the fatfs capacity, it will be truncated, which is certainly not what you want. Symlinks manipulation should really be avoided. I think this was never documented or suggested, but people discovered this possibility and started to use it on their own risk. This is a strong alarm that we need to add more flexibility, so that they just stop adding the symlinks and start to use what we provide and suggest.

[stsp]

All you should do is to alter $_hdimage.

I meant to say "All you can do is to alter $_hdimage". Altering hdimage is not any better than changing the symlinks - its the same thing, but at least it is documented. We need to add some more mechanisms of mapping the DOS drives.

[jschwartzenberg]

$_hdimage is in .dosemurc which is also dotted :)

Basically there are four ways to map a drive

1. edit $_hdimage
2. put a symlink (so that it matches with a wildcard in $_hdimage)
3. emufs
4. lredir

You're saying there should be more mechanisms. I hope the documentation will be good ;)

I do not really understand why 2 would be worse than 1 as comes down to the same thing as far as I can see. 2 is kind of the Wine-way btw.

[stsp]

$_hdimage is in .dosemurc which is also dotted :)

/etc/dosemu/dosemu.conf is not dotted though. Well, fiddling with hdimage is not the good thing to do either. Originally this was supposed to be used to specify the native DOS partition to boot from, or, well, a real hdimage file. If you don't have either, you shouldn't change $_hdimage, except for the fact that currently we don't have the alternative... But we should.

Basically there are four ways to map a drive

You forgot DOSDRIVE_D.

You're saying there should be more mechanisms.

Not necessarily more, in numbers. 2 and 3 should not be used, 1 has its own problems (but the truncation I mentioned above, should actually be visible only in a "kvm" branch right now, as other branches has the hack to mitigate that). So there should actually be fewer. I'd add DOSDRIVE_EXTRA defaulting it to ~/dosemu - should be quite sufficient to be the only way of allocating the drives, unless you have a native DOS partition or an image file, in which case you alter $_hdimage, and that's all. The advanced users can use lredir2 too, but nothing more.

I do not really understand why 2 would be worse than 1

2 is an undocumented way, and if people start to depend on it, this may trouble some functionality additions. For example if you check the latest devel, there are not only symlinks in ~/.dosemu/drives. There are new things now, which I can change again and again. This is just an internal thing, not something the users should change, or the things may break. In contrast, I need to keep $_hdimage compatible, as it was documented and used.

[bartoldeman]

Actually all the methods (except emufs.sys) were documented in http://dosemu.sourceforge.net/docs/README/1.4/

And dotted files and directories are very much meant to be edited by users, it's just that they are reserved to the application. A more modern way would be to use the ~/.local hierarchy.

Of course if you want to break things you can, I may not agree but dosemu2 is your project so I am not going to spend too much time arguing, I can only give a historical perspective :)

[stsp]

Actually all the methods (except emufs.sys) were documented in http://dosemu.sourceforge.net/docs/README/1.4/

Well, 2 is documented in a chapter "1.3. Using a different DOS" together with $hdimage, which, more or less, agrees with what I say above. As I said, I do not suggest changing $hdimage unless you have a different DOS partition, and changing the symlinks is the same thing. So in that chapter it can exist, but please don't change it for the default freedos installs. Yes, I wouldn't recommend to change the symlinks even for the different DOS, but at least it is not as important as long as you don't change it in a default configuration. So the tweak to this doc is, if needed, would be small.

Of course if you want to break things you can, I may not agree but dosemu2 is your project so I am not going to spend too much time arguing, I can only give a historical perspective :)

I am not sure to what you refer as a breakage here, as there are many things I am about to "break" (DOSDRIVE_D, drive_z, put files instead of symlinks to "drives" etc). So please be specific. :)

[stsp]

not going to spend too much time arguing

Much better time-spending would be to discuss the alternatives. Defending the old methods without discussing the alternatives is really quite unhelpful, but thanks for the historical reference - at least I'll make "-home" functional again.

[stsp]

I mean, really, Bart, I proposed quite a few possibilities already and all you do is just saying that I am breaking your favourite $HOME folder. This is not productive. If you think my proposals are not important enough to be discussed, then I can fairly do the same about your only proposal to not touch the home dir. But who will win from such affairs is unclear.

[jschwartzenberg]

I do think it'd be nice to have an option to get to your homedir quickly. It's also something I've used a lot. Before today, I did that by dumping a symlink in ~/.dosemu/drives to my homedir.

I guess there are two main approaches to the whole problem:

1. Have a mostly static set-up which is defined in the configuration (and through the file system) and can be expected to be the same in every dosemu instance (comparable to Wine)
2. Have a set-up which can be influenced quickly each time dosemu is launched by passing arguments on the command line. Different dosemu instances are more likely to have different drive mappings (comparable to dosbox)

As a user I would prefer the first situation. (Also my dosbox configuration has some static drive mappings.) There are obvious arguments for the second one as well though.

[stsp]

I do think it'd be nice to have an option to get to your homedir quickly.

That's what "-home" did - I'll repair it to do its work.

As a user I would prefer the first situation.

What you wrote are not mutually exclusive "solutions" at all. dosemu just defines 3 drives (used to define 2 before my recent changes) statically, with the rest being possible to allocate dynamically (not yet, DOSDRIVE_EXTRA).

There are obvious arguments for the second one as well though.

Lets just have both.

[stsp]

I do not really understand why 2 would be worse than 1 as comes down to the same thing

So, if we use the old doc Bart points to, we see that:

1. both are undocumented for freedos
2. both are documented for "different DOS" From that we can also conclude these are the same things.

So:

• The use of both with freedos is undocumented and discouraged.
• The use of changing $hdimage is perfectly fine for "other DOS"
• The use of changing symlinks is fine for "other DOS" per the old doc, but not per my suggestion. This looks like the very minor problem, as I don't think "other DOS" setup is still in a wide use. So if the doc to stop mentioning symlinks for "other DOS" case, I don't think anyone would get sufficiently hurt.

[jschwartzenberg]

But technically there's no difference in just changing $_hdimage or pointing $_hdimage to some directory plus a wildcard with symlinks in it. Also I do not really see why FreeDOS and other DOS would be different.

[bartoldeman]

I am just saying if you break things it's up to you -- I just don't agree about $HOME, that's all. I can easily re-point D: to $HOME in my own setup. I found the default with D:=$HOME easiest to describe-- using ~/dosemu encourages the creation of that dir in the user namespace when it may already be used for other purposes (e.g. to put the dosemu source code).

I also wanted to point out that ~/.dosemu/drives was documented -- and the .dotted namespace in $HOME is just the personal equivalent of /etc. Putting files instead of symlinks adds flexibility so that is great.

The change with config.sys -> fdconfig.sys may be confusing. Lots of DOS installers change config.sys and with fdconfig.sys those changes won't be taking effect.

The documentation I wrote in 1.3 is a bit confusing I admit. It really talks about 2 different setups:

1. put io.sys/msdos.sys in ~/.dosemu/drive_c then the rest will be as with FreeDOS
2. having a bootable FAT partition (which can also be FreeDOS of course). In that case the config.sys/autoexec.bat of that drive take effect (by default) so the initial state is exposed with D: having the dosemu commands.

What exactly else I need to test more carefully and I am going to be offline for the coming week. There are some changes with unix.com and system.com that confuse me still, I should recheck where their stdout is going, does "$ dosemu -dumb dir > listing" and things like dosemu "/home/clarence/games/commander keen/keen1.exe" still work, etc, I'll test that all later.

[stsp]

But technically there's no difference in just changing $_hdimage or pointing $_hdimage to some directory plus a wildcard with symlinks in it.

$hdimage also allows you to add directories, rather than just point to the different location. And that added location can also contain the set of symlinks, etc. So that gives you a bit more flexibility, but at the end it is technically just the same thing. Being the same thing technically, doesn't imply the same use though. Documentation should always be consulted first, because if you deduced some functionality yourself, no one guarantees it will remain the same in the future.

Also I do not really see why FreeDOS and other DOS would be different.

As you can see from the doc, they are. :) For "other DOS" we should distinguish between using the existing "other DOS" setup (on a real fat16 partition, this is what I use) and doing "other DOS" setup by dosemu. Doing other DOS setup by dosemu - is a moving target, something you wanted to achieve with your scripts, etc. So for now I omit this case. As for the "existing other DOS setup" - I hope it is quite obvious why it is different from the "new freedos setup". Obviously in the former case you need to adjust $hdimage just to point dosemu where to look for that existing setup. You then also need $emusys and other trickery.

[stsp]

I am just saying if you break things it's up to you -- I just don't agree about $HOME, that's all.

And that's the problem: you call a breakage what is not. If you don't agree with $HOME, I leave an option for you, which was always there but stopped working on 1.4. If you want to call it a breakage, you should consider that I actually fix the "-home" option, which in 1.4 doesn't do anything at all. It used to do things in pre-1.4 dosemus, so the breakage happened in 1.4, and I am just restoring it to stay compatible with an older versions where it worked fine. Of course the reasoning can be inverted based on the real use-cases, but I don't remember a single feature request asking for that change, I don't remember any discussion or documentation of rationale behind this change, etc. So I am much inclined to view that as a breakage, not my attempt to restore it to original. Of course, as with any other change, people had to adopt it in a mean time, so fixing this will mean some (small) breakage to someone... And of course everything have to be done to make the transition painless, like providing a working option, rather than a non-working one.

using ~/dosemu encourages the creation of that dir in the user namespace when it may already be used for other purposes (e.g. to put the dosemu source code).

OK, lets not do ~/dosemu by default. I am just collecting an opinions.

I also wanted to point out that ~/.dosemu/drives was documented

For "other DOS". For freedos it is not, and for a reason.

and the .dotted namespace in $HOME is just the personal equivalent of /etc.

That's if you are talking about a dotted files, but we are talking about a dotted dirs. Entirely different things. There are almost never a documented suggestions like "go to /home/stas/.mozilla/firefox/7sy8po6z.default and edit your prefs.js there". But dotted files in $HOME is indeed just a settings overrides.

Putting files instead of symlinks adds flexibility so that is great.

And that's why I don't suggest to make the changes to symlinks at all. Today they work, tomorrow - there are only files, who knows? I am not planning such a change, but better safe than sorry.

The change with config.sys -> fdconfig.sys may be confusing. Lots of DOS installers change config.sys and with fdconfig.sys those changes won't be taking effect.

This is in preparation for supporting the different DOSes, including their out-of-box installation. Unfortunately, every DOS needs a different config.sys. Fortunately, many DOSes can already use a different file name for that. drdos also has its own config name, for instance. So the simplest solution is to just start using these names. Even if some installer adds the DEVICE to config.sys, the chances are high this will not work under dosemu, and it can break the boot-up instead. We can also provide a "stub" config.sys and invoke it via a CHAIN directive (currently available only on drdos), although I'd rather use some other name, not config.sys, for such stub. Essentially the config.sys changes under dosemu should be done with a great care by the experienced users, because it is not the same as under pure DOS. Installers can just mess it up by trying to add the dosemu-incompatible device drivers. Example: QEMM. Run its installer under dosemu, and you are unbootable.

stdout is going, does "$ dosemu -dumb dir > listing"

No. New syntax: dosemu -dumb -TqE dir >listing

and things like dosemu "/home/clarence/games/commander keen/keen1.exe" still work

Yes, although just as a compatibility option, because openwatcom depended on that. New syntax is -K. Note that despite the compatibility efforts, openwatcom should be updated from git to work with dosemu, and dosemu should be updated from git too, as I had to submit many changes to both projects to make them compatible. I am pretty sure openwatcom doesn't build on 1.4 too, but it could be working with some older dosemus. Anyway, now everything works again, which is good. Hope people are updating from git frequently enough. :)

[stsp]

dosemu -dumb -TqE dir >listing

Even newer syntax, after recent commits: dosemu -dumb -qE dir >listing

[stsp]

Consider a poor user of other virtual machines. He sees some garbage on drive D (linux file names truncated to 8.3 with broken local-charset names) and erases them with F8 in his Norton Commander. Big deal, he thinks - I'll just reinstall the VM if something goes wrong. How would he be surprised, when he noticed that all his $HOME is now wiped...

As for ntvdm and wine: none of them are a virtual machine. ntvdm does not load DOS, and wine does not load windows. Wine provides you with an ability to run windows progs, giving them the native look-n-feel, integrating them with your desktop, etc. ntvdm does the same: you work in cmd.exe - a win32 app, and that one allows you to run both win32 apps natively, or it runs ntvdm to run the DOS binary.

dosemu OTOH is a virtual machine. It boots DOS, and from its command.com you run only DOS programs, all in the same window. It is not comparable with wine or ntvdm, and I would be very surprised if virtualbox or some other VM would expose your $HOME by default to the guest. We need to minimize the chances for the user to trash his entire account with our app. And you propose to maximize it instead.

[stsp]

So, having $HOME exposed:

1. populates D with garbage
2. gives the user a big risk of trashing his entire account by deleting things that just shouldn't be there
3. no other VM is doing the crazy things like this.

If 3 is true (I can't check all the VMs myself, so please put up the info here), and 1 and 2 are certainly true, I really see no point in even discussing this. This is just something that should have been reverted silently and quickly, as a malicious backdoor or the like.

[kalpha2]

valid points, but if deviating from dosemu1 and want to be either a drop in replacement for it or a not to painful upgrade from it.... you may want to at least make clear in doco (of changes from dosemu defaults?) and or provide option to have? You can default it to not with all your dire warnings if changed. Do you envisage dosemu2 eventually being packaged in the major distros? As dosemu or dosemu2? For existing users of dosemu should they expect an upgrade wizard....

[stsp]

and or provide option to have?

Of course. I stated many times here that the "-home" option will stay. More so, it will be repaired to actually do what it did before the 1.4 breakage of it. This is not an incompatible change, if you consider older dosemus than 1.4. I don't see why should I stay compatible with one particular version and not with another.

Do you envisage dosemu2 eventually being packaged in the major distros?

I hope so, but in most cases this will mean me or someone very close to dosemu2 to do the packaging work. The package maintainers of today's distros are unlikely to be very interested by another dosemu variant, so they may be reluctant to do the work themselves.

As dosemu or dosemu2?

Open question. My own preference would be dosemu2, but I envision the counter-arguments, so at the end it is up to the packagers.

For existing users of dosemu should they expect an upgrade wizard....

Hope not. Things like $HOME unexporting would happen automatically without a wizard. And whatever can't be done automatically, should be supported for compatibility (like old config/autoexec).