EDR F5/F8 handling and SvarCOM compatibility

[mateuszviste]

This is not a bug nor a feature request, rather a request for comments.

When F5 or F8 is pressed during the FreeDOS kernel bootup, the kernel appends different switches to COMMAND.COM:

F5 -> executes "COMMAND.COM /D /P /E:256" so COMMAND.COM knows it has to skip AUTOEXEC.BAT F8 -> appends /Y to the COMMAND.COM SHELL= invocation so COMMAND.COM knows it has to execute AUTOEXEC.BAT in step-by-step mode or, if no SHELL is present in CONFIG.SYS (or the SHELL directive has been denied by the user) it executes "COMMAND.COM /Y /P /E:256"

EDR, on the other hand, does not append anything. When I press F5, the explicit CONFIG.SYS "SHELL" directive is skipped, so SvarCOM is executed without any parameters (no /P -> no autoexec). Coincidentally, planets align here and the end result is fine, although it is pure luck.

When I press F8, then:

• if I accept the "SHELL=COMMAND.COM /P" directive, then autoexec is executed right away (without step-by-step) because the shell is invoked exactly as it appears in the SHELL directive
• if I deny the "SHELL=COMMAND.COM /P" directive, then autoexec is not executed at all because EDR invokes the shell without /P (without any argument, really).

Should EDR use the same "command.com bootup protocol" as FreeDOS? Ie. execute COMMAND.COM with "/P" by default, with "/P /D" if F5 is pressed and with "/P /Y" if F8 is pressed?

Or should SvarCOM learn how to interact with EDR? How the shell can know whether:

• it is the primary (initial) shell
• F5 has been pressed at boot time
• F8 has been pressed at boot time

Adapting EDR to follow the FreeDOS protocol would have the desirable side effect of making the F5/F8 business work with FreeCOM.

[boeckmann]

I started documenting the internal, you may have a look at how the EDR kernel does this: https://github.com/SvarDOS/edrdos/blob/main/doc/internals.md

[mateuszviste]

wow, quite some hoops to jump through I see :D So basically we should avoid having users running a FreeCOM + EDR combo, as this part would be clearly dysfunctional. For SvarCOM it is not a big problem, I will add the necessary support. However, I need to be able to detect that it is an EDR kernel that is being booted so bootcode discovery can be applied only then. Is there some specific EDR signature that I could look for?

[boeckmann]

However, I need to be able to detect that it is an EDR kernel that is being booted so bootcode discovery can be applied only then. Is there some specific EDR signature that I could look for?

You may query the EDR version via INT21,4452, which should otherwise return with carry set: https://github.com/SvarDOS/edrdos/blob/a1a43a42a0585b54fa6ae2f67fe2bca8e2726d32/drdos/ioctl.asm#L319-L328

If you only want to know if you are running EDR, you may combine it with querying the private data pointer via INT21,4458. That should also return carry set if it is NOT EDR.

https://github.com/SvarDOS/edrdos/blob/a1a43a42a0585b54fa6ae2f67fe2bca8e2726d32/drdos/ioctl.asm#L409-L413

[boeckmann]

In addition, if you implement querying the private data: EDR command sets the config environment segment to zero after reading. I did not find anything that depends on it. But it is probably a good idea to indicate root shell initialized.

[boeckmann]

https://github.com/SvarDOS/edrdos/blob/a1a43a42a0585b54fa6ae2f67fe2bca8e2726d32/command/cstart.asm#L2767-L2784

[mateuszviste]

Thank you, Bernd! It is all extremely helpful. I will look into implementing the necessary bits in SvarCOM soon.

[mateuszviste]

According to RBIL the 4458h call is DR-DOS specific, so I guess it should fail (CF set) on other DOSes (hopefully). I am unsure I understand this segment-to-kernel-environment thing, though. internal.md states:

query the config environment by getting a pointer to the kernel private data and inspecting offset 12h to get the segment of the environment.

So I would think that offset 12h contains the segment where the kernel's environment is stored. But RBIL has this worded a bit differently:

12h WORD pointer to segment of environment variables set in CONFIG, or 0000h if already used

I find this "pointer to segment" confusing. Is this really some kind of WORD pointer? Reason I ask is that I am getting garbage when trying to output the kernel environment, so surely I am doing something wrong, because such code:

yields such result:

[boeckmann]

Have you tried to put something in the environment via

SET XX=ABC

in config.sys to see if this is displayed?

[mateuszviste]

Have you tried to put something in the environment via

SET XX=ABC

in config.sys to see if this is displayed?

Did not, was expecting "something" there already (a zero char at least, or the 1Ah terminator), but you are right, this is a good test. I am away from my PC now, will test it tomorrow.

[boeckmann]

On my system the config env segment is 9FABh. If I run the following code directly as a shell, it prints the env correctly:

.model small
.stack 512
.code
    .startup
    mov ax,4458h
    int 21h
    mov ax,es:[bx+12h]
    mov ds,ax
    xor dx,dx
    mov ah,9
    int 21h
    mov ax,4c00h
    int 21h
end

HOWEVER: If I run this code under SvarCOM the env segment contains garbage. So my guess is that SvarCOM overwrites the environment? It would not be to blame, because this is not marked as reserved space.

[mateuszviste]

Ah, so the kernel env is stored in some "wild" (unallocated) memory? The segment you mention is quite high in memory (past 610k or so). When SvarCOM starts, it allocates a 2k chunk of memory as high as possible, for its resident code. Hence indeed, it is possible that this resident code overwrites the wild environment. :-/ A workaround would be for SvarCOM to read the environment before installing its resident code, but if kernel relies on unallocated memory for its operations then I am afraid that troubles will follow sooner or later anyway...

[mateuszviste]

not sure why this is closed -- must have been some misclick on my part

[boeckmann]

Yes, it is a "wild" pointer. But this data is supposed to be copied by the DR command.com as soon as possible. So these are tightly coupled in this regard. When seeing the code for this I already had the impression that this could impose be a problem. But this is the only wild pointer I found so far.

Perhaps this could be mitigated by allocating a MCB for it. But then this MCB would have to be freed by command.com...

If copying the env before relocating SvarCOM does not work we should try to take the MCB route or another approach...

[mateuszviste]

...or maybe the F5/F8 detection could be made simpler (not relying on the internal kernel env)?

[mateuszviste]

I am getting the same env segment as you (0x9FAB). However, the kernel environment starts with two NULs. Is that expected?

@mateuszviste no this should not be the case. And I already found that the INITENV segment was not properly paragraph aligned, causing this. Will be fixed with the next commit.

[boeckmann]

INITENV alignment fixed via https://github.com/SvarDOS/edrdos/commit/a9adbbf2fb4077a8eff2e443b428da8c3e803623

[mateuszviste]

Thanks! I confirm that now the kernel env lives at seg 0x9FAC and starts immediately with actual content (each variable zero-separated, like in the usual environment). It is zero-padded to exactly 255 bytes and terminated with a 1Ah character, then followed by a key scancode - either 0x00 (no key press), 0x3F00 (F5) or 0x4200 (F8).

Example when F5 is pressed:

All very interesting stuff. But still, quite a headache just to figure out whether F5/F8 have been pressed :-P

[boeckmann]

All very interesting stuff. But still, quite a headache just to figure out whether F5/F8 have been pressed :-P

That's true, but you could also use it to build the master environment :) Can you please set the config env segment in the DR-DOS private data area offset 12h to zero after reading it?

[mateuszviste]

That's true, but you could also use it to build the master environment :)

That's on my radar, although it would make things (in SvarCOM) even more or a flying circus so not sure I will go through with it. My short term goal is to at least get the F5/F8 business working.

Can you please set the config env segment in the DR-DOS private data area offset 12h to zero after reading it?

Yes, I am doing it already. Not committed yet because I want to have proper F5/F8 support first, but that should not be long now.

[mateuszviste]

not sure why this is closed -- must have been some misclick on my part

Wasn't a misclick after all, I see now I had this forked into https://github.com/SvarDOS/bugz/issues/88

Anyway -- F5/F8 detection works now so I am closing both issues. @boeckmann Thank you for your help!