Dosemu2 test suite test `test_create_new_psp` still failing on current git master about kernel HOT 9 CLOSED

Hello @andrewbird,

Hmm... this is one area where Ralf Brown's Interrupt List turns out to be wrong. (It says "the parent PSP field is set to 0", but that is only the case for MS-DOS 1.x.)

Thank you!

from kernel.

@tkchia , I can't claim to understand the full significance of the parent PSP field, as I remember @stsp was looking for a problem with the PSP on FDPP and asked me to write a test to establish the values on several flavours / versions of DOS. This test was the result of that investigation and has remained within the test suite since. I have some other failing tests with FreeDOS GIT around FCB file functions when using wildcards, but I'll wait until later to see how easy it is to document those in a manner that doesn't require people to run dosemu and the test suite itself.

Thank you!

from kernel.

Please refer to this comment:
dosemu2/fdpp#112 (comment)
But I don't think it is possible to
get this game to work on freedos.
The problem with zeroed out PSP
is just one of many tricks it does
to detect the DOS clones. I think
me and Andrew spent many months
on reverse-engineering the full scheme.

from kernel.

Hello @andrewbird, hello @stsp,

@tkchia , I can't claim to understand the full significance of the parent PSP field, as I remember @stsp was looking for a problem with the PSP on FDPP and asked me to write a test to establish the values on several flavours / versions of DOS.

Hmm... I decided to look at the open-sourced MS-DOS 1.x and 2.x code a bit.

It seems that DOS 1's command.com uses the int 0x21, ah = 0x26 syscall to create a new PSP when running a child program.

• (Yes — in DOS 1, the code to start a new child process is in the interpreter, not the kernel.)
• Basically the call just copies whatever is in the current process's PSP (which cs is assumed to point to...).
• I do not think any DOS 1.x programs actually depend on their PSP's "parent PSP" field being any particular value.

As for MS-DOS 2.x, its exec syscall (int 0x21, ah = 0x4b) is actually internally implemented in terms of several other syscalls, one of them being int 0x21, ah = 0x55.

• Unlike 0x26, this will specifically create a child PSP, whose "parent PSP" field points back to the current process's PSP.
• (In addition, RBIL says that "the reference count for each inherited file is incremented".)

So — on second thought — my current guess is, in terms of documented behaviour, there is no actual guarantee that the parent PSP that comes out of ah = 0x26 should be any particular value. It will probably be a "good-to-have feature", but not super-essential, to make FreeDOS's behaviour match that of MS-DOS in this case.

But I don't think it is possible to get this game to work on freedos.

Well, games that do anti-debugging tricks to try to detect emulators are always interesting... :-)

Thank you!

from kernel.

Our ticket ends on anti-debugger tricks,
but elsewhere we analyzed lots of tricks
to detect dos clones (like resizing psp
to 0 and many more).
DOS is full of undocumented behaviour,
so I do not support your judgement
based on that, but unless you can make
the whole game to work, this is indeed
absolutely unimportant to support.

from kernel.

Hello @stsp,

Well, important or not, I have submitted a pull request... :-) Thank you!

from kernel.

The test case passes now, which pleases me greatly!

ajb@polly:/clients/common/dosemu2.git$ test/test_dos.py FRDOSGITTestCase.test_create_new_psp
Test FR-DOS-GIT  Create New PSP                                                  ... ok (  3.11s)

----------------------------------------------------------------------
Ran 1 test in 3.137s

OK

Thank you!

from kernel.

Then you may as well dig the rest of
the changes to get the aforementioned
game working. Which would be an
interesting quest, as there were lots of
false-starts, reverted changes etc.
That game was a real pita.
Lets see if you can. :)

from kernel.

The patch is now applied.

Thank you!

from kernel.