Qbix from this thread:

In the current design of dosbox it's very hard near impossible to do. […]
Show full quote

In the current design of dosbox it's very hard near impossible to do.

That's because it's hard to recreate the call stack of the cpu cores.
This is because of the fact that the shell is merged into dosbox instead of seperated. The shell can therefore starts it's own cpu core. (more than 1 cpu core is working at the sametime. Quite hard to recreate that from a savefile i think.

Not to mention file changes. Those will be horrible.

Anyway. Don't count on it happening soon. I think we should go for more compatibility and more speed first.

There is an added benefit for developers, one that was the deciding factor in MAMEDEV adding savestates to MAME, for better or for worse.

Say you have a user who says: "When I get to level 8 on game XYZ, Dosbox crashed with this error message...". Well, perhaps QBix is not a good-enough gamer to get to level 8? How is he going to debug this? Well, he could use a level-up cheat if there is one, but you cannot guarantee that the crash will be repeatable at this point. Or what if the game offers saves? You can't guarantee that both the user and the developer will have the exact same revision of the game. So the best solution is to implement savestates - or at least incredibly detailed crash-logging - so you can debug the code.

Of course, now with MAME, a change can be implemented in a CPU core and break previous savestate compatibility. So you take what you can get...

However, I agree with QBix's assessment - this is a feature best left for much further down the road.

The benefits are without question most useful, but the bulk of the problem is
capturing dosbox's state. ie Although a memory grab is easy, its the
re-setting all of dosbox's internal structures & variables (that are constantly in source-code flux) that is the largest headache.