Hi Jerome, thanks for reading the flood of mails :-)
> The warm boot is an alias in the FDAUTO. Basically, it is a line > inherited from FreeDOS 1.1 that I’ve never bothered to change. I think coldboot would be more reliable. > What config bugs??? > > I am aware of no bugs in the current config files. > > I have be asked to make some changes to some things to possibly increase > compatibility > or boost performance for some installs. Things like “please load a CD cache” > because > it is slow on my hardware. Yes. No show-stoppers, but things like "the first and recommended boot option uses daring emm386 options and may crash for some people", or inconsistencies between descriptions and implementations of the different boot options. Also please load UHDD before UDVD2 so it can provide a cache for both harddisk and CD. If your driver detection choses ELTORITO, also add CDRCACHE as separate CD cache. I personally would also appreciate loading MORESYS, but that is of course a bit unusual. >> See my 2021-05-03 mail on freedos-devel, >> "Distro autoexec/config wishes for 1.3rc4" ... > Its not really the bad As it is difficult for me to predict which config file contents will be used on which hardware, it could be useful to start a thread where you post a typical, say "real Pentium 1 or VM" style config as copy-paste content so I can do finger-pointing at actually used lines that seem problematic ;-) Of course you can also wait with that until you have integrated the updates you were going to add anyway :-) > For example, without pipes, you can’t do > > grep -i “FDAPM” *.BAT | grep -iv “COLDBOOT” That comment was mostly about Jim's video, which is why I had sent it only to Jim at first. Of course one should really have a writeable temp directory, because pipes are useful, but when people happen to be in a situation without one, it is good if the video also talks about how to avoid pipes. > First, the installer does not automatically format or > partition the HD if a existing writable drive C: is found. So it automatically switches to "just copy files" mode in that case? I was not aware of that based on what I saw in the video. > Things outside the %DOSDIR% (usually C:\FDOS) should > be fine. Great :-) Also, I have now watched the "advanced installer" video from Jim. That one has almost exactly the amount of choices I like to have in installers, thanks :-) But see my comment above, if the non-advanced installer will automatically switch to overwriting only C:\FDOS without any partitioning or formatting, that also already covers most wishes. Maybe the installer could check whether there is a FreeDOS directory instead of or next to a FDOS directory, maybe check which of them are mentioned in config, fdconfig, autoexec or fdauto as a tie breaker and then assist the user in selecting where to put and/or overwrite a previous FreeDOS directory. But that is of course just a bonus, not required. By the way, I GUESS that you default to using fdconfig and fdauto files instead of config and autoexec files to reduce overlap with other OS in a dual boot situation or when people might go back to their other DOS later? In that case, you should probably install command.com in the FDOS directory, not in the root directory, to further reduce the overlap? Otherwise, I would recommend to use the classic config and autoexec names. People are used to them and some app installers actually edit the config files so it is good if they can be found automatically. I think if you find pre-existing files of either or both names, you could ask the user what the installer should do: Keep, rename, overwrite etc. As far as I understood Jim's video, you already have a similar question in the installer, but it was not clear for me whether that is about the boot files, config files, FDOS directory or all. In particular, does ZIP-ing (or renaming?) the previous files include the FDOS directory? Or is it only about boot and config files? About the "red alert" theme: Just mention the word "advanced" somewhere on screen. People may not stay aware that "red" is a reference to that difference, even if they had to manually start "SETUP ADV". Which brings me to the next question, why not put that choice in the interactive installer menu? As far as I understood the video, people have to abort install to get to a prompt, then manually start advanced install, that is less intuitive. > I’ve been revisiting my thoughts on this lately... > > There are many users who want to always see > every option when installing FreeDOS. > > However, the overwhelming majority of users are > running FreeDOS in some sort of VM and... Depends. If they simply see the options of base and full automated install and advanced install with more choices, everybody can be happy :-) > There is a third option to consider > > Detection of a QEMU, VirtualBox and VMWare How about Bochs? DOSEMU2? DOSBOX? Why would you assume that people with VM have different needs than people with plain hardware? I think your main argument is that people with VM tend to make empty VM from scratch and want a simple way to throw DOS on empty disks without having to answer too many questions. But that applies also to people with empty harddisks on real hardware. Also, people with VM can easily already have data on their virtual disk. In that case, they are in the same situation as people with real hardware who already have data. So in short, I would not make the install depend on whether your hardware is real or not, but on what data you already have on your disk :-) Of course you can automatically change EMM386 options to work around some known VM bugs. Do we know which of them exist and in which VM? Note that real hardware can ALSO be affected: For example VME helps a lot with DOS speed if EMM386 is loaded, but the 2017 generation of Ryzen had broken VME. So you may want to use CPUID to detect those and add the VME command line option for EMM386 only for all others. A more "DOS age style" way to do this would be to just add comments to config sys and start with a high compatibility config, but invite users to read the config files and edit them at the commented places. For example very few users may have DMA-broken LiteON CD drives. A comment in the config file can mention that UDVD2 /UX can be tried to make such drives work, but the option should NOT be added by default, because it wastes performance for everybody with non-broken CD drives. Another example is that VME and, even more so, PGE are pretty safe and useful in EMM386, while NOINVLPG (which excludes PGE) and NOVME might be needed for some virtual hardware which has known shortcomings in CPU emulation. So THAT is something you could actually put into the config based on VM detection: If people have no VM, they will have to read the comment and edit options manually if they are among those rare users of incompatible CPU, but if they do have a VM with known bugs, the safe command line option could already be put automatically. I still recommend using X=TEST, but not I=TEST, on all hardware. See above about VME or NOINVLPG. Other interesting EMM386 options: EMX, VERBOSE, X2MAX=32767 and SB, which are all useful when working on increased compatibility with "exotic" apps and drivers, so they could be mentioned in a config file comment for those who fail to spot them in the rather long readme of EMM386 :-) And last but not least, I suggest to load UHDD before EMM386: This can reduce conflicts between broken BIOS, which fail to do protected mode DMA properly, and EMM386. Users who are not loading EMM386 at all of course are less affected, but their protected mode DOS apps might still be. Thanks for considering all those :-) Eric _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
