Reboot for MSDOS
Dan Peknik
Hi!
Is there an MSDOS command line 'reboot' utlity out there somewhere?
Thanks for any info,
-Dan
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dan Peknik - Software Quality Engineer
NeXT Computer, Inc.
dan_p...@next.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
William Hutto
>
>Hi!
>
>Is there an MSDOS command line 'reboot' utlity out there somewhere?
>
>Thanks for any info,
>-Dan
>
Yeah!
Save the following as reboot.txt
-----------------------------snip here---------------------------------
a
jmp ffff:0
rcx
5
n reboot.com
w
q
---------------------------------snip here-----------------------------------
Then from the command line type:
C:\>debug < reboot.txt
Which creates reboot.com
Bill
"Whatcha got on?...Your mind?"
Adam Nikic
: Hi!
: Is there an MSDOS command line 'reboot' utlity out there somewhere?
: Thanks for any info,
: -Dan
Yep. Here it is. You will find two files inside the reboot.zip. They are:
BOOTCOLD.COM 21 .a.. 2-22-94 11:40:22 pm
BOOTWARM.COM 21 .a.. 2-22-94 11:40:20 pm
I bet you will guess the purpose of both files.
Enjoy,
Adam
begin 644 reboot.zip
<uuencoded_portion_removed>
end
DONALD G. DAVIS
>Is there an MSDOS command line 'reboot' utlity out there somewhere?
Run DEBUG < SBOOT.SCR on the following file:
A 0100
MOV AH,0D
INT 21
MOV AX,40
MOV DS,AX
MOV WORD PTR [72],1234
JMP FFFF:0000
N SBOOT.COM
RCX
14
W
Q
This will create a reboot utility that will flush file buffers to
disk and then do a soft reboot (i.e., skip the POST and memory tests).
--Donald Davis
Chris Huey
: >Is there an MSDOS command line 'reboot' utlity out there somewhere?
: >
: >Thanks for any info,
: >-Dan
:
: Yeah!
:
: Save the following as reboot.txt
: -----------------------------snip here---------------------------------
No! This won't shut down SmartDrv nor any memory managers. This must
be one of the most FAQs on this group. Ah well...
From a posting last July by jfu...@oneworld.owt.com (J.P. Fulks):
<><><><><><><><><><><><><><><><> SNIP <><><><><><><><><><><><><><><><><><><>
The following code is an excerpt from the Microsoft Developer's Network CD
concerning rebooting from a batch file:
The executable file can be created using DEBUG as follows:
1. Start DEBUG by typing the following at the MS-DOS command prompt:
debug
2. At the dash prompt, enter the following sequence of commands, each
followed by pressing ENTER. (Comments are preceded by ";".)
A 100 ; Debug instruction for assemble
MOV AH,0D ; Disk Reset
INT 21h ; causes SmartDrv 4.x to write cache
MOV AX, 40 ; set up segment addressing
MOV DS, AX
DS:
OR BYTE PTR [17],0C ; equivalent of pressing CTRL+ALT
MOV AX,4F53 ; Issue a "DEL" (53h = DEL scan code)
INT 15h ; EMM386 sees this & shuts down
DS:
MOV WORD PTR [72],1234 ; Set REBOOT flag to Warm-Boot (0=cold)
JMP F000:FFF0 ; Execute the internal restart routine
<CR> ; This line must be blank (just hit ENTER)
R CX
20 ; File size to be written to disk (in hex)
N REBOOT.COM ; Filename
W ; Write the file to disk
Q ; Quit Debug
NOTE: The REBOOT.COM file created with this debug script is compatible
with SMARTDrive and its write-behind cache feature. The instructions
in REBOOT.COM cause SMARTDrive to write (flush) its write-behind cache
to disk before the computer is rebooted.
This procedure creates the file REBOOT.COM in the current directory.
At this point, you can call the file in the same manner as any other
executable file, either from the command line or within a batch file,
and the system will reboot.
<><><><><><><><><><><><><><><><> SNIP <><><><><><><><><><><><><><><><><><><>
Chris
--
Chris Huey Tactix ReEngineering, Inc.
c...@tactix.com Voice: (503) 684-3582
Just another hitch-hiker on the Information Super-highway.
Bernardo Reino Romero
On 12 Jan 1996, Dan Peknik wrote:
> Is there an MSDOS command line 'reboot' utlity out there somewhere?
>
> Thanks for any info,
> -Dan
>
I don't know, but you can make your own.
If you want a warm reboot, assemble this code:
mov ax,40h
mov ds,ax
mov bx,1234h
mov ds:[072h],bx
push ffffh
push 0000h
retf
If you want a cold reboot change the 1234h to 0000h.
Another way is to simulate the 'reset' button:
cli
@@wait:
in al,64h
test al,02h
jnz @@wait
mov al,0feh
out 064h
Hope it helps.
Ari Lukumies
>
> On 12 Jan 1996, Dan Peknik wrote:
>
> > Is there an MSDOS command line 'reboot' utlity out there somewhere?
> >
> > Thanks for any info,
> > -Dan
> >
>
> I don't know, but you can make your own.
>
> If you want a warm reboot, assemble this code:
>
> mov ax,40h
> mov ds,ax
> mov bx,1234h
> mov ds:[072h],bx
> push ffffh
> push 0000h
> retf
>
This is _absolutely_ wrong! Returning (ie. jumping) to FFFF:0000 jumps you to the
beginning of the code the CPU runs after the power is switched on in the computer, thus
running Power-on-self-test (POST) and initializing every board, chip etc. Instead of
doing the two PUSH's and the RETF, the correct thing to do is:
int 19h
THIS will yield to warm boot.
> If you want a cold reboot change the 1234h to 0000h.
>
Or, you can use the code with those PUSHs and RETF.
> Another way is to simulate the 'reset' button:
>
> cli
> @@wait:
> in al,64h
> test al,02h
> jnz @@wait
> mov al,0feh
> out 064h
>
> Hope it helps.
>
Later,
AriL
--
All my opinions are mine and mine alone.
Ray Moon
> This is _absolutely_ wrong! Returning (ie. jumping) to FFFF:0000 jumps you to the
> beginning of the code the CPU runs after the power is switched on in the computer, thus
> running Power-on-self-test (POST) and initializing every board, chip etc. Instead of
> doing the two PUSH's and the RETF, the correct thing to do is:
>
> int 19h
>
> THIS will yield to warm boot.
NO, issuing int 19h by itself can leave the computer in a very unstable
condition. The original posting was correct for a warm reboot.
An example would be a TSR loaded at the command line which has hooked a BIOS
interrupt. Issuing int 19h will not reinitialize the interrupt table. Even
if that code is not overwritten immediately, that part of memory is free and
available.
For a more detailed discussion, please see my x86 Assembly Language FAQ,
subject 31 in the General Section, part III. You will ned the Jan 96 version
because this subject was just added.
The FAQ is posted by me around the 21st of every month. The FAQ also is
available at
ftp://rtfm.mit.edu/pub/usenet-by-group/alt.lang.asm/
or
ftp://rtfm.mit.edu/pub/usenet-by-group/comp.lang.asm.x86/
Lastly, I zip all the sections of the FAQ and upload them to SimTel. The
lastest file is available:
ftp://ftp.coast.net/SimTel/msdos/info/asm9601.zip
I have uploaded asm9601.zip but it may not be available for downloading yet.
Ray
Ray Moon
Simon Hosie
> This is _absolutely_ wrong! Returning (ie. jumping) to FFFF:0000 jumps you to the
> beginning of the code the CPU runs after the power is switched on in the computer, thus
> running Power-on-self-test (POST) and initializing every board, chip etc. Instead of
> doing the two PUSH's and the RETF, the correct thing to do is:
> int 19h
> THIS will yield to warm boot.
THAT will crash a lot of computers.
Glen Blankenship
> This is _absolutely_ wrong! Returning (ie. jumping) to FFFF:0000 jumps
> you to the beginning of the code the CPU runs after the power is switched
> on in the computer, thus running Power-on-self-test (POST) and
> initializing every board, chip etc.
Well, yes, but that's what a warm boot *should* do. The only difference
between a warm boot and a cold boot is that the warm boot doesn't do the
memory check, and that's what setting the Memory Check Flag to 1234h is for.
> Instead of doing the two PUSH's and the RETF, the correct thing to do is:
>
> int 19h
>
> THIS will yield to warm boot.
No, sorry. Int 19h does NOT reboot. It merely reloads the boot sector
from disk. It skips a number of important steps, including reinitializing
the interrupt vector table. This can cause the machine to crash when the
new instance of the OS overwrites TSR and device driver interrupt
handlers that weren't unhooked.
There are circumstances under which the direct jump to FFFF:0000 won't
work (not to mention good arguments for using F000:FFF0 as the destination
address), and it may cause data loss if write-caching disk software is
in use. These issues are covered in considerable detail in this group's
FAQ list.
Still, it's much closer to a correct answer than "use Int 19h".
---
Glen Blankenship
obo...@netcom.com
John Murphy
says...
>This is _absolutely_ wrong! Returning (ie. jumping) to FFFF:0000 jumps you
to the
>beginning of the code the CPU runs after the power is switched on in the
computer, thus
>running Power-on-self-test (POST) and initializing every board, chip etc.
Instead of
>doing the two PUSH's and the RETF, the correct thing to do is:
>
> int 19h
>
>THIS will yield to warm boot.
Int 19 DOES NOT REBOOT THE MACHINE!!! This myth seems to raise its ugly
head every few weeks, but it's still just as false as it ever was. (Where on
earth did this idea come from?!) If you invoke Int 19 and your machine
actually reboots, you should drop whatever you're doing and make a quick
trip to Vegas; Lady Luck is not only smiling on you, she's grinning from ear
to ear.
Murf
Ari Lukumies
>
> NO, issuing int 19h by itself can leave the computer in a very unstable
> condition. The original posting was correct for a warm reboot.
>
> An example would be a TSR loaded at the command line which has hooked a BIOS
> interrupt. Issuing int 19h will not reinitialize the interrupt table. Even
> if that code is not overwritten immediately, that part of memory is free and
> available.
>
> For a more detailed discussion, please see my x86 Assembly Language FAQ,
> subject 31 in the General Section, part III. You will ned the Jan 96 version
> because this subject was just added.
>
Ok, I agree I was wrong, but then again, I haven't been doing warm booting from a program
lately... Sorry for the fuss. Still I don't think jumping to a boot vector is very good an
idea. What if you have a memory manager (such as 386Max) that can map RAM in place of
unused ROM code?
Hardin Brothers
Ari Lukumies <ar...@cmt.lpr.mail.carel.fi> wrote:
>Ok, I agree I was wrong, but then again, I haven't been doing warm booting
from a program
>lately... Sorry for the fuss. Still I don't think jumping to a boot vector is
very good an
>idea. What if you have a memory manager (such as 386Max) that can map RAM in
place of
>unused ROM code?
>
>Later,
> AriL
Your concern is absolutely correct.
As I understand it, there are 2 ways that a program should NEVER
reboot (on a 286 or later):
call int 19h -- because the interrupt vector table is not reinitialized
jump to f000:ffff or something similar. The problem with this is that
the BIOS code is written to expect the CPU is in full reset condition,
in real mode, and with registers in a known state. If you do this
from V86 mode, for example, you are likely to hang many machines.
If Debug breakpoints are active, interrupts enabled, etc. etc., you
may also cause a hang. However, this is the ONLY safe way to
reboot on an 8088
So how does a program reboot?
IF running on 8088, jump to f000:ffff
ELSE
IF on MCA (and some EISA systems):
in al,92h
(twiddle your thumbs a bit)
or al,1
out 92h,al
ELSE
send a command to the keyboard controller to pulse the reset line
(this technique can also be used on MCA systems --
it's just a little slower)
Of course, all of this happens after you set the appropriate boot flag
at 40:72h :
0000, 1234, 4321, or 0064 (some systems)
-- Hardin
Charles Dye
har...@RT66.com (Hardin Brothers) wrote:
> [bogus methods deleted]
>So how does a program reboot?
> IF running on 8088, jump to f000:ffff
> ELSE
> IF on MCA (and some EISA systems):
> in al,92h
> (twiddle your thumbs a bit)
> or al,1
> out 92h,al
> ELSE
> send a command to the keyboard controller to pulse the reset line
> (this technique can also be used on MCA systems --
> it's just a little slower)
>
>Of course, all of this happens after you set the appropriate boot flag
> at 40:72h :
> 0000, 1234, 4321, or 0064 (some systems)
>
> -- Hardin
BUT FIRST, the all-important call to Int 21 .AH=0D. Otherwise, SmartDrive
may clobber your hard drive! (Most particularly under DOS 6.0; an incautious
reboot can frag an entire DoubleSpace volume. Not Fun.)
Paul Schlyter
> So how does a program reboot?
> IF running on 8088, jump to f000:ffff
really must be in real mode for this method to be reliable. In any
V86 mode this may cause the PC to hang.
> ELSE
> IF on MCA (and some EISA systems):
> in al,92h
> (twiddle your thumbs a bit)
> or al,1
> out 92h,al
> ELSE
> send a command to the keyboard controller to pulse the reset line
> (this technique can also be used on MCA systems --
> it's just a little slower)
instructions are not allowed in the ring where this code runs. In
application code, this worked fine in Win 3.1 but stopped working in
Win 3.11. To safely reboot your PC from any recent version of Windows,
you must put this code where it has unrestricted access to the machine,
for instance in a VxD.
> Of course, all of this happens after you set the appropriate boot flag
> at 40:72h :
> 0000, 1234, 4321, or 0064 (some systems)
your harddisk partially corrupt after the boot, usually in the form
of "lost clusters".
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pau...@saaf.se p...@home.ausys.se
Julian Jose Menendez San Francisco
> >
> > mov ax,40h
> > mov ds,ax
> > mov bx,1234h
> > mov ds:[072h],bx
> > push ffffh
> > push 0000h
> > retf
> >
> This is _absolutely_ wrong! Returning (ie. jumping) to FFFF:0000 jumps you to the
> beginning of the code the CPU runs after the power is switched on in the computer, thus
> running Power-on-self-test (POST) and initializing every board, chip etc. Instead of
> doing the two PUSH's and the RETF, the correct thing to do is:
> int 19h
The address you have to jump to is FFFF:FFF0 I think...
--
__ __ _ _____
## |__| |__| |\ | | \ | | ## Asturnet 98:985/30.6 * VMail 70:348/2.6
## |___| | | | \| |_/ | | ## Internet i142...@petra.euitio.uniovi.es
... Hay cosas que, para saberlas bien, no basta con haberlas aprendido. (K|S)