Hi Jerome, of course the installer is complex because it is more USEFUL that way, but loading a cache is useful as well and that is a piece of complexity you do not have to write yourself :-)
You simply have to dare to use it in the installer. As have lots of users on their installed system for decades. >> If you really want the installer to have a totally foolproof >> boot option, make sure that it avoids JEMMEX and JEMM386 >> unless the user choses to use them. Make sure that the EMM >> always avoid I=... options. Add some of the fool-proofing >> options for EMM to VM compatibility, as far as not done yet. > Ummm. The install boot media doesn’t load much of anything. > It doesn’t load JEMM*. It only loads HIMEMX. Then later a > RAM Drive, CD Driver and Extensions may be loaded. Sorry about mixing up topics here. The installed system will default to "daring" JEMM... options, the installer itself does not. But see below about whether it might. > It may actually be better to not load HIMEMX, remove the > DOS HIGH stuff and load all drivers low. That would severely impact the ability of the installer to do anything useful at any decent speed. Please restrict the scope of such extreme measures to the 8086 floppy edition. HOWEVER, now that you mention it: You cannot load drivers high without JEMM... at all ;-) You could use UMBPCI as replacement, but UMBPCI only works on suitable hardware. So if you want to have more DOS RAM free, you should try to load JEMM... with some "humble and safe" options and give the user the choice whether or not they want to try loading JEMM... or rather prefer a safer HIMEM-only way. The good news is that DOS=HIGH (kernel) and XMS SWAP in our command.com already help a LOT for having more RAM free even if you have only HIMEM! So you really really want to load HIMEM (or XMGR or even FDXMS286, if 286) whenever you can. You can actually even use the /H options to load UHDD and UDVD2 into HMA to save more RAM even if you do not have any UMB because you chose to not load JEMM... :-) Caveat: because of FreeDOS kernel limitations, you must load UHDD and UDVD2 via DEVLOAD, not in config sys, to let /H take the desired effect. >> Now if you manage to BREAK your beloved VirtualBox or >> VMWare by loading a cache, I can probably give you some >> quick support by recommending different command line >> options, but you first have to manage to break it ;-) > > I don’t know why you think I’m fond of VirtualBox and VMware. Because you mentioned that most users would use those and not use any actual hardware to install FreeDOS on, which was your argument for not needing any cache for speed and for focusing on the "entire harddisk contains nothing, not even any MBR, partitions or filesystems" scenario as one of the most important ones for the installer to handle. > I have no first hand knowledge of any problems with the current > build of FreeCOM. I have not tested it myself. I have only seen > posts about the issue. But, that issue would make it unusable. > I assume it will be fixed eventually. The fix already is in the GIT sources, as Jim noticed, so a fixed binary can be expected soon. I hope Jeremy finds the time to update the documentation before doing so. As you can see in the GIT sources, he has started with that. Cheers, Eric :-) _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
