>>     MOV SS,CS:[SaveSS]      ;now we can appreciate the
 >> automagic int disable
 >>     MOV SP,CS:[SaveSP]      ;and it protects us during this
 >> move too
 >  I'm sure there is a trick or a confusion about the running code and
 > debuging the code. when debuging code, the debugger steps over SP since
 > we are running in V86 mode (EMMXXX). Maybe its for something else.
Most debuggers execute the instruction after the mov SS: for 2 reasons:
A> The CPU doesn't permit a single-step interrupt immediately after a mov SS:
instruction
B> Most debuggers know that to execute, they themselves need a valid stack.
They _know_ that whilst ss: has changed and SP has not, the stack is not 
valid. They also _know_ that the very next instruction is usually a 
SP-modifying instruction, so they simply ASSUME that is the case and execute 
the next instruction without breakpoint. That way, the debugger assumes that 
the stack will again be valid, and continues on.
There are also issues with the CPU itself - I'm not sure, but I'll bet that 
most CPU's would have an interesting time if you tried to insert a breakpoint 
instead of the mov sp command - it would probably execute on early 8088/8086 
(the ones without the automatic protection) but with all later 8088+, it 
would be real curious, since interrupts are disabled at that point, who knows 
what might happen.
Remeber that in order to execute a breakpoint, the first thing that happens 
is the return address is put on the stack....but right now SS:SP isn't 
valid.... even if that works, the first thing a breakpoint handler usually 
does is enable interrupts... but SSP:SP _still_ isn't valid....
It might be interesting to set up some test code to experiment with here, but 
I'll give you even money you just crash, either just after soon into your 
breakpoint handler.
    Craig
--- FMail/386 1.20+
---------------