On 2004-02-27, Alain Mouette wrote:
>> True that once long time ago it was discussed that the rebooting
>> method of jumping to certain BIOS point wasn't "safe" in the sense
>> that wasn't portable across BIOSes, but it was s long time ago
>> that I may be wrong.
>> Thanks :)
>
> Well, it _al
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 th
Hallo Bart and Steffen,
It goes all the way back to kernel 2024a released Apr 16 2001. Before that
kernel there was a p_0() function in task.c.
Around that time we were making huge gains in the memory usage of the
kernel. First Tom implemented HMA support (before that the resident part
of the kern
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=4
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:
When process0 is about to be spawned
On Sun, 29 Feb 2004, FreeCOM wrote:
>
> > * init_call_p_0() will need to (in a .asm file):
> > set SS and DS to the DOS data segment (DGROUP, cs:[_DGROUP_])
> > set SP to the top of a special p_0 stack (how many bytes for that
> > stack?)
>
> Why not use the I/O stack (char_api_tos)? When pr
* init_call_p_0() will need to (in a .asm file):
set SS and DS to the DOS data segment (DGROUP, cs:[_DGROUP_])
set SP to the top of a special p_0 stack (how many bytes for that
stack?)
Why not use the I/O stack (char_api_tos)? When process0 terminates & the
InDOS flag is set, this stack sho
Following this discussion I looked at when and why I removed the
code we're talking about from HMA_TEXT.
It's not as easy as a mere code save.
It goes all the way back to kernel 2024a released Apr 16 2001. Before that
kernel there was a p_0() function in task.c.
Around that time we were making h
On Sat, 28 Feb 2004 16:16:34 +0100, Steffen Kaiser wrote:
Well, but because those two are assigned to the terminate address of process0, you must initialize them. Regardless from where you start the Load-Process0 function.
Done now, but obviously your warning below is right.
Um, BTW: process0 mus
On Thu, 26 Feb 2004 21:34:26 +0100, Steffen Kaiser wrote:
maybe I totally misinterpreted the stuff, but Init_DosExec() from within kernel()
loads process0, right?? Init_DosExec eventually ends up in DosExec() -- or at least in
a function identical to it??
DosExec() spawns for example DosComLoade
Luchezar Georgiev wrote:
I tried to change user_r->CS and user_r->IP, but the linker complained.
Well, but because those two are assigned to the terminate address of
process0, you must initialize them. Regardless from where you start the
Load-Process0 function.
Um, BTW: process0 must also have
On Thu, 26 Feb 2004 21:34:26 +0100, Steffen Kaiser wrote:
Just found a way to do it! Just before executing the shell, "setvec(0x22, shutdown)". In new_psp(), after "p->ps_isv22 = getvec(0x22);", compare the vector to shutdown and if it matches, "setvec(0x22, int22_handler);". Voila! Expect the pat
True that once long time ago it was discussed that the rebooting method
of jumping to certain BIOS point wasn't "safe" in the sense that wasn't
portable across BIOSes, but it was s long time ago that I may be wrong.
Thanks :)
Well, it _allways_ was sefe and documented to jump to :0, but a
Luchezar Georgiev wrote:
Eureka! Just found a way to do it! Just before executing the shell,
"setvec(0x22, shutdown)". In new_psp(), after "p->ps_isv22 =
getvec(0x22);", compare the vector to shutdown and if it matches,
"setvec(0x22, int22_handler);". Voila! Expect the patch in a couple of
ho
On Thu, 26 Feb 2004, Luchezar Georgiev wrote:
> On Thu, 26 Feb 2004 08:48:17 +0100 (CET), Steffen Kaiser wrote:
>
> > As you showed, the "reloading" of the shell is performed by the kernel
> > in MS DOS. I do not suggest to copy this behaviour
>
> Neither do I. ROM-DOS expects the user to type a n
On Thu, 26 Feb 2004 20:22:03 +0300 (MSK), Arkady V.Belousov wrote:
1. _How_ to perform reboot process?
2. How to be with (write delayed) caches?
OK, OK, you're both right - won't reboot right away! ;-)
1. command.com should prevent (if possibly) to exit from primary copy.
Would be good, but not m
On Thu, 26 Feb 2004 18:27:05 +0200, I wrote:
[...] perhaps all we have to do is set the Int 22h termination address of the shell's PSP to stopSystem and it'll be
That's what I meant; because the kernel does not do anything different when process0 terminates than when any other process ends.
OK. Bu
Luchezar Georgiev escribio':
On Thu, 26 Feb 2004 20:22:03 +0300 (MSK), Arkady V.Belousov wrote:
1. _How_ to perform reboot process?
2. How to be with (write delayed) caches?
OK, OK, you're both right - won't reboot right away! ;-)
Sorry, I missed this. In KEYB there's a little piece of code to
Hi!
26-Фев-2004 10:29 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
>> Now power off or reboot" message.
LG> Or simply reboot without waiting for the user! It's the only thing he can do
LG> at this point anyway.
1. _How_ to perform reboot process?
2. How to be with (write del
On Thu, 26 Feb 2004, Luchezar Georgiev wrote:
> misty to me, but perhaps all we have to do is set the Int 22h
> termination address of the shell's PSP to stopSystem and it'll be
That's what I meant; because the kernel does not do anything different
when process0 terminates than when any other pro
Arkady V.Belousov escribio':
ASM> Sorry, I missed this. In KEYB there's a little piece of code to perform
ASM> such a reboot with flushing caches beforehand, mainly kindly contributed
ASM> by Matthias Paul, with a few lines added by myself. If need be.
(forgot to add: (1) as Eric pointed, not need
Hi!
27-Фев-2004 01:22 [EMAIL PROTECTED] (Aitor Santamari'a Merino) wrote to
[EMAIL PROTECTED]:
>> I don't think that this (_not_ well-defined nor safe code) should be
>>included into kernel.
ASM> Can you please define what is "safe" or "well defined"?
"Well defined" - explained in well-
Hi!
27-Фев-2004 00:13 [EMAIL PROTECTED] (Aitor Santamari'a Merino) wrote to
[EMAIL PROTECTED]:
>>> 1. _How_ to perform reboot process?
I mean: is there well-defined and safe process?
>>> 2. How to be with (write delayed) caches?
>> OK, OK, you're both right - won't reboot right away! ;-)
A
Hi,
Arkady V.Belousov escribio':
Hi!
27-Фев-2004 01:22 [EMAIL PROTECTED] (Aitor Santamari'a Merino) wrote to
[EMAIL PROTECTED]:
I don't think that this (_not_ well-defined nor safe code) should be
included into kernel.
ASM> Can you please define what is "safe" or "well defined"?
On Thu, 26 Feb 2004 13:32:47 +0100 (CET), Steffen Kaiser wrote:
On Thu, 26 Feb 2004, Luchezar Georgiev wrote:
misty to me, but perhaps all we have to do is set the Int 22h
termination address of the shell's PSP to stopSystem and it'll be
That's what I meant; because the kernel does not do anythin
void stopSystem(void) {
puts("\nThe system has shutdown. Please reboot or power off.");
for(;;) _asm hlt;
}
in persistent memory and process0 gets "stopSystem" as termination address?
The question is how to determine whether the teminating process is process 0?
I see now! Your suggestion is good an
On Thu, 26 Feb 2004 08:36:06 +0100 (CET), Steffen Kaiser wrote:
a) Who or what shallt reload command.com? And _which_ command.com?
The user may type a new shell name. But even this is not mandatory. At least it must not crash!
b) On what reason shallt the EXIT command be blocked without the /P sw
On Thu, 26 Feb 2004 08:48:17 +0100 (CET), Steffen Kaiser wrote:
As you showed, the "reloading" of the shell is performed by the kernel in MS DOS. I do not suggest to copy this behaviour
Neither do I. ROM-DOS expects the user to type a new shell name. But even this is not mandatory.
but to have a
On Thu, 26 Feb 2004, Luchezar Georgiev wrote:
> On Wed, 25 Feb 2004 18:11:45 -0300, Alain wrote:
>
> >> To crash after typing "EXIT" just because I don't have /P on my SHELL line is not
> >> very nice! ;-)
> >
> > Agreed. IMHO the crash should be avoided by a) reloading command.com, b) blocking
On Wed, 25 Feb 2004, Alain wrote:
> > To crash after typing "EXIT" just because I don't have /P on my SHELL
> > line is not very nice! ;-)
>
> Agreed. IMHO the crash should be avoided by a) reloading command.com, b)
> blocking the "exit" command, c) anything ;-)
Well, I don't remember if this sug
On Wed, 25 Feb 2004 18:11:45 -0300, Alain wrote:
To crash after typing "EXIT" just because I don't have /P on my SHELL line is not very nice! ;-)
Agreed. IMHO the crash should be avoided by a) reloading command.com, b) blocking the "exit" command, c) anything ;-)
Here's how other DOSes handle this
To crash after typing "EXIT" just because I don't have /P on my SHELL
line is not very nice! ;-)
Agreed. IMHO the crash should be avoided by a) reloading command.com, b)
blocking the "exit" command, c) anything ;-)
Alain
---
SF.Net is sponso
On Wed, 25 Feb 2004 21:45:42 +0200, I wrote:
main.c is init code. It may be disappeared by the time you exit command.com.
I found the exact place when it crashes. After the the IRET instruction at the end of exec_user(). The code executed just after this instruction is at the former INIT segment,
On Wed, 25 Feb 2004 19:47:33 + (GMT), Bart Oldeman wrote:
main.c is init code. It may be disappeared by the time you exit command.com.
I found the exact place when it crashes. After the the IRET instruction at the end of exec_user(). The code executed just after this instruction is at the form
On Wed, 25 Feb 2004, Luchezar Georgiev wrote:
> Salve,
>
> When I EXIT from primary shell (loaded without explicit /P by
> "SHELL=FREECOM.EXE" in FDCONFIG.SYS), the kernel crashes with "Invalid
> Opcode" instead of showing "System shutdown complete / Reboot now". Any
> suggestions? The code in the
On Wed, 25 Feb 2004 21:19:06 +0200, I wrote:
When I EXIT from primary shell (loaded without explicit /P by "SHELL=FREECOM.EXE" in FDCONFIG.SYS), the kernel crashes with "Invalid Opcode" instead of showing "System shutdown complete / Reboot now".
SoftICE shows that the crash happens in INT 21 AX=4C
On Wed, 25 Feb 2004 21:10:42 +0200, I wrote:
When I EXIT from primary shell (loaded without explicit /P by "SHELL=FREECOM.EXE" in FDCONFIG.SYS), the kernel crashes with "Invalid Opcode" instead of showing "System shutdown complete / Reboot now". Any suggestions? The code in the CVS main.c between
On Wed, 25 Feb 2004 20:44:53 +0200, I wrote:
When I EXIT from primary shell (loaded without explicit /P by "SHELL=FREECOM.EXE" in FDCONFIG.SYS), the kernel crashes with "Invalid Opcode" instead of showing "System shutdown complete / Reboot now". Any suggestions? The code in the CVS main.c between
Salve,
When I EXIT from primary shell (loaded without explicit /P by "SHELL=FREECOM.EXE" in FDCONFIG.SYS), the kernel crashes with "Invalid Opcode" instead of showing "System shutdown complete / Reboot now". Any suggestions? The code in the CVS main.c between lines 398 and 426 seems OK, but...
Lu
39 matches
Mail list logo
