Return to Answer

MS-DOS doesn't offer any special facilities that I'm aware of related to switching to a different stack, but they're not really necessary since switching is a simple matter of saving the old SS:SP pair and loading your new values.

Early MS-DOS didn't offer any special facilities for switching to a different stack, though of course there's nothing stopping anybody writing an interrupt handler from just saving the old SS:SP pair and loading new values pointing to an area of memory they've allocated. But starting in 3.2 MS-DOS could be configured to allocate additional stack areas and switch to them after receiving a hardware interrupt but before calling its handler. See Eric Towers' answer for details.

The ARM implmentation of faster interrupts had a separate set of hardware registers that replaced r8 through r14 during an FIQ. The only effect this has on the stack is that less needs to be pushed, so it could reduce the chance of stack overflow, but the program counter and flags still needed to be pushed anyway, so it didn't completely eliminate this.

The ARM implmentation of faster interrupts had a separate set of hardware registers that replaced r8 through r14 during an FIQ, meaning that you don't need to push them on the stack at all, saving the time it takes to do that. (It's actually a little more complex than this, due to user vs. system mode and other things, but none of that is really relevant to this question.)

So the basic approach you'd take its to leave as much extra space on the stack, beyond your program's requirements, as reasonably possible, and try to ensure that any interrupt handler routines you write either use the minimum possible amount of stack (as with the Bochs INT 08 handler above), and hope for the best.

So the basic approach you'd take is:

1. Leave as much extra space on the stack, beyond your program's requirements, as reasonably possible. If you get close to using 64K in your own stack, consider using multiple stack segments to keep a reasonable amount of free space in every one.
2. Try to ensure that any interrupt handler routines you write use the minimum possible amount of the interrupted program's stack. Consider allocating your own stack area and switch the stack to that shortly after entering the handler if you use more than a few dozen bytes of stack space.
3. Hope for the best.

MS-DOS doesn't offer any special facilities that I'm aware of related to switching to a different stack, but they're not really necessary since switching is a simple matter of saving the old SS:SP pair and loading your new values.