Hi,
> On Jun 15, 2021, at 7:36 AM, Eric Auer <e.a...@jpberlin.de> wrote:
>
>
> Hi Jerome,
>
> thanks for reading the flood of mails :-)
:-)
> [..]
>> 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 :-)
It’s not really that bad.
Basically, If a version for a specific platform doesn’t exist. The Default
version is used.
Extensions are
086-686: for CPU specific.
DBX: for DOSBox
VBX: for VirtualBox
VMW: for VMware
(a couple others not used a present)
So, when installed on a 386 the installer looks for AUTOEXEC.386 and
CONFIG.386. If they don’t exist, it uses AUTOEXEC.DEF and/or CONFIG.DEF.
If the installer detects a 486, it looks for 486 variants. But, it will
not use the 386 or lesser ones. It is a simple either — or situation. If not
486 version, DEF is used.
> [..]
>> 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.
There is more to it than that of course. A way, way, way over-simplification…
welcome to installer
Is there a writable drive C:? If so skip to config temp space.
Is there a Drive, but it has no DOS partitions?
Is there a Drive C:, but is not writeable and needs formatted?
config some temp space for I/O redirection (if needed)
find install media packages
ask install questions to configure installer.
begin install
Maybe backup DOSDIR, system and config files to dir or a zip archive
Remove conflicting packages (since may be outside of DOSDIR and will
cause FDINST to fail on file conflicts)
Maybe remove entire DOSDIR dir
Install new packages
Maybe Setup Boot sector
Maybe Install system Files
Maybe Install config files
Maybe someday, I’ll do a flow chart of the installer logic.
>
>> 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?
There are a couple reasons it uses FDAUTO and FDCONFIG.
Partly for the reason you mention.
Partly to show they are for FreeDOS and FreeDOS is different from
MS/PC/Open/etc-DOS.
Partly because installers love to break MY config files. This allows them to do
whatever they want to AUTOEXEC and CONFIG. Then I can add the changes myself if
needed.
Partly because they sort closer together in dir lists.
Probably some other partlies as well. :-)
>
> 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.
If the installer detects old config files, it offers to back up the previous OS.
> 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?
Basically, all of that.
When doing the zip archive (only offered in advanced mode), it does the normal
backup, then
compresses that into an archive. More or less just to conserve space.
>
> 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”.
The “Welcome” screen says “Welcome to the advanced installer…” when in advanced
mode.
The “Red Alert” Theme just a theme. It is akin to a couple linux desktops of
yesterday. When logging into a desktop as root, some distros would use a red
backdrop with bombs all over it.
> 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.
Not up to me.
You can switch to advanced mode without exiting the installer. But, it’s easier
to explain to just ue the “adv” option.
>
>> 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
At present, I’m not aware of any tool that does a test for “Is Drive ? Empty”.
Maybe all add that to V8Power Tools when I have the time.
:-)
Jerome
>
>
>
> _______________________________________________
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
