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, https://github.com/dosemu2/fdpp/blob/f2962dbace7d5c838fc06375bd6fc0200232ce33/kernel/task.c#L264

[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.