On Sun, 29 Feb 2004, Bart Oldeman wrote:
> On Sun, 29 Feb 2004, FreeCOM wrote:
> > Bart Oldeman wrote:
> > >>Why not use the I/O stack (char_api_tos)? When process0 terminates & the
> > >
> > > this may be possible but tricky in C. As the code must make sure it
> > > doesn't use any stack that it relies from before int21/ah=4b after
> > > int21/ah=4b.
> > I don't understand:
> you're right that the stack doesn't matter for
> mov ax,4b00
> int 21
> (ie. the cs, ip that are pushed now are stored in the PSP so these aren't
I believe you do approach the problem differently; I do not attempt to
have a _loop_, but create an environment (through the PSP) that directs
the command flow to a catch-up hook in the kernel, once process0
Let's sketch me my scenario "from the back":
0. process0 is going to be terminated, that means at some time the kernel
1. return_user() resets cu_psp to process0's ParentPSP, the DOS_PSP?
2. The user stack and INTs from DOS_PSP are restored. Which shall be
pointing to internal kernel hooks, e.g. the autofail Critical Error
handler and the ignore ^Break handler. The stack is on char_api.
3. The return address is poked onto the stack and POP$ALL/iret takes
place. The iret takes the program flow to the kernel-internal
4. This hook now is already running on an kernel stack; you have to setup
the DS frame and ++InDOS flag in order to simulate the same environment as
if the kernel had been enterred through entry.asm.
5. Now you can call any kernel function, including DosExec(), now.
Here the prompt user - try DosExec() loop would be placed.
You are right. The DosExec() parameters must exist somewhere in memory and
if they are made automatic/local to the "hook function", they could
overflow the char_api stack; so it would be needed to find another
location for them, e.g. any kernel-internal memory, not overwritten by
DosExec(), e.g.: disk_api stack, SecPathBuffer, ... .
I do not attempt to have a "loop" implemented, but to have a "longjmp()"
style mechanism. Each time process0 terminates, the kernel behaves like
making a longjmp() to a recovery function; this function re-initiates the
loop -- the loop itself is only functional, when DosExec() fails. Also, I
do not attempt to keep an old command line once DosExec() had succeeded.
For the initial loading, I see two ways:
a) the loop remains unchanged -- only picking up failed DosExec()
conditions. Duplicating the code of step 5).
b) pass the SHELL= command line somehow to the "hook" and jump right to
step 5) -- I mean literally jump to the part in the kernel that implements
the process0-terminated hook.
In both cases, DOS_PSP has to be initialized properly with SS:SP and