Re: Feedback needed on BOOTING, CACHING and some HELPER TOOL

On Wed, 6 Nov 2002, Steffen Kaiser wrote:

> Eric Auer wrote:
> | 0x81 get swapped? Bart also writes that autoexec.bat is only read from A:
> | or C: when boot drive is "any floppy" or "any harddisk" (at least for
> hard-
>
> Actually, FreeCOM executes "\autoexec.bat" and does not care about the
> drive issue.

This is because Eric says what I said slightly differently :) I said that
DOS sets the current drive to either A: or C: depending on the BIOS drive
(<0x80 or >=0x80) it was booted from.

actually maybe I was wrong about B: but certainly not about D: in any case
the FreeDOS code is:

    if (BootDrive >= 0x80)
      BootDrive = 3; /* C: */

> | Bart also reminded me that FreeDOS -does- have a "prompt for path to the
> | command.com" which gets active when the shell is not found or exits un-
> | expectedly. I was accidentally requesting the feature again :-). MS DOS
> | has this as well. You can enter any program that can stand not having a
> | parent process as your new shell at that kernel prompt, I would say.
>
> Not, if my memory serves me right, MS DOS v6 kernel prompt and the MS
> COMMAND v6 prompt are identical. (I suspect it's the _same_ code.) If MS
> DOS v6 shall execute a non-MS COMMAND v6 shell, SHELL= must be present.
> DOS 7 is different, though, as it does not make those simple COMMAND.COM
> checks at all.

I don't know about MSDOS 6. FreeDOS gives this phrase:
"
Bad or missing Command Interpreter: 2 -  /E:8096 /P


Please enter the correct location (for example C:\COMMAND.COM):
"

The "2" here is cryptic -- probably a bug somewhere.

By the way, trying to use FreeCOM (beta46) as primary command shell with
MSDOS 7.1 I get this (using shell=c:\freecom.com /e:8096 /p):

"
FreeCOM executable not found.
You must specify the complete path to COMMAND.COM
as the first argument of COMMAND, for instance:
C:\FDOS



The shell is about to be terminated, though, this is
forbidden (usually by enabling the "/P" option).
You must reboot the system or, if this shell runs in
a multitasking environment, terminate this process/task manually.

"

No big deal, but just to mention it. Using the suggested
shell=c:\freecom.com c:\ /e:8096 /p
does not help. This could be a bug in DOS 7.1, because the FreeDOS kernel
handles this just fine :)

Bart