alpha waves crashes DN on exit

[stsp]

It only starts fine with comcom32
(but crashes on exit).
I think freecom does something with psp
that freedos does not recover. The last
executed function is 0x50.
Needs to compare psps after starting
from these command.coms.

[stsp]

Can't reproduce the "doesn't start with freecom"
part any longer.

[stsp]

I am not sure 9c4a468 was correct.
Andrew, you seem to have a PSP test,
could you please check if file table
pointer at offset 0x34 copied or updated
by int21/26h?

[stsp]

Broken again.

[stsp]

This is mostly "fixed" with
DR-DOS findings about 0x26
and the hack to increment stdio
fds refcount.
But still crashes if started under
DN and then one exits from DN.

[stsp]

Things are getting weirder.
It appears that both PC and MS
DOSes on 0x26 populate the
psp_parent and psp_file_table
with some crap/uninitialized content.
So I don't understand how 0x4c
on such PSPs can ever work...

[stsp]

No longer crashes since we route
GPFs to freedos these days. So now
it just gives the error dump from
freedos, but everything works thereafter.

And is completely "fixed" with this:

index 9b67fcc..5764412 100644
--- a/kernel/memmgr.c
+++ b/kernel/memmgr.c
@@ -426,7 +426,7 @@ COUNT DosMemChange(UWORD para, UWORD size, UWORD * maxSize)
   /* MS network client NET.EXE: DosMemChange sets the PSP              *
    *               not tested, if always, or only on success         TE*
    * only on success seems more logical to me - Bart                                                                                                                   */
-  p->m_psp = cu_psp;
+//  p->m_psp = cu_psp;
   fd_prot_mem(p, sizeof(*p), FD_MEM_READONLY);
 
   return SUCCESS;

Very strange...

[stsp]

Seems fixed...
@ecm-pushbx do you happen to
know what int21/26h should set the
parent_psp to? Too many sources
claim different things. RBIL says
it is zeroed out. I thought it should
remain unchanged. AlphaWaves seems
to assume it is set to parent, similar
to what 55h does.
What do you think?

[stsp]

Mm, it should probably be set to CS.
That would explain many confusions
around it.
Thoughts?

[ecm-pushbx]

Seems fixed... @ecm-pushbx do you happen to know what int21/26h should set the parent_psp to? Too many sources claim different things. RBIL says it is zeroed out. I thought it should remain unchanged. AlphaWaves seems to assume it is set to parent, similar to what 55h does. What do you think?

I tested this on MS-DOS 7.10, and it initialises the process being created from the user CS:0. The parent field is not written after this by function 26h so if CS = PSP you will get the same parent as the CS PSP has.

You can read this in the free software MS-DOS v2 sources at https://github.com/microsoft/MS-DOS/blob/04a3d20ff411409ab98474892b2bb1713bde0f7f/v2.0/source/MISC.ASM#L541

The branch to Create_PDB_cont is taken for function 26h so PDB_Parent_PID is not written later on. It does seem like the Process Handle Table is handled differently in MS-DOS 7.10 for function 26h, I get the PHT count reset to 14h (20) and the pointer set up to point into the created PSP. The contents of the 20-byte PHT are copied (and presumably dupped) from the source PSP's PHT, in my case CCCCh:CCCCh.

Here's a photo of the debugger dumping a created PSP. I made sure to fill the CS:0 area with CCh bytes before running function 26h:

[stsp]

Thanks!
I re-pushed the fix.
Indeed, the culprit was CS!=current_psp... :(
There are other instances of that problem,
too, see #185.
I think at least fn 55h also needs the same
treatment?

[stsp]

As for PHT - fdpp dups only stdio fds
on fn 26h. Duping all of them, or duping
neither, causes AlphaWaves to malfunction.
This game checks the msdos-compat
behavior too thoroughly. :(

[ecm-pushbx]

Thanks! I re-pushed the fix. Indeed, the culprit was CS!=current_psp... :( There are other instances of that problem, too, see #185. I think at least fn 55h also needs the same treatment?

No, function 55h explicitly copies the MS-DOS v2 style "current process", you can see that in https://github.com/microsoft/MS-DOS/blob/04a3d20ff411409ab98474892b2bb1713bde0f7f/v2.0/source/MISC.ASM#L534

Dup_PDB is the function 55h entrypoint and it sets the variable to distinguish its behaviour from function 26h:

        procedure   $Dup_PDB,NEAR
ASSUME  DS:NOTHING,ES:NOTHING
        MOV     BYTE PTR [CreatePDB], 0FFH  ; indicate a new process
$Dup_PDB    ENDP

CREATE_PROCESS_DATA_BLOCK is the function 26h entrypoint. I think it has the CreatePDB variable zeroed out somewhere in the int 21h dispatcher.

[ecm-pushbx]

As for PHT - fdpp dups only stdio fds on fn 26h. Duping all of them, or duping neither, causes AlphaWaves to malfunction. This game checks the msdos-compat behavior too thoroughly. :(

Do you mean you're dupping only handles 0 to 4? I'd expect it to dup the first 20 handles.

[stsp]

0 to 2 currently.
Duping all 20 didn't work.
I put some comments to task.c.
Comment says drdos does not dup any.

[ecm-pushbx]

0 to 2 currently. Duping all 20 didn't work. I put some comments to task.c. Comment says drdos does not dup any.

Ah yeah,

fdpp/kernel/task.c

Line 264 in f2962db

/* DR-DOS says:

[stsp]

I would appreciate if you debug this
game on your own. :) Its initial support
took a lot of debugging (of myself and
Andrew), but at the end I resorted to the
"best guess" technique. So probably the
changes were not accurate. But properly
disasming and verifying everything would
take too much.