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 > lost).
Hello Bart, 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 terminates. Let's sketch me my scenario "from the back": 0. process0 is going to be terminated, that means at some time the kernel enters return_user(). 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 process0-terminated hook. 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 int22/23/24. Bye, -- Steffen Kaiser ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
