ripsaw8080 wrote:keenerb wrote:it'd just be fixing whatever's keeping this one single app from working.
Your use of the word "just" suggests that you don't really appreciate what would be involved. For starters, it would involve rewriting a large portion of DOSBox's internal DOS to emulate the SFT (System File Table) in real DOS instead of being based around the various data structures it uses now. There are plenty of things to improve in DOSBox before something like that would ever happen, so you're just (!) going to have to get by with booting real DOS.
I'm not a developer, I can only ask for input from people who DO know, like yourself. I certainly didn't mean to offend by using "just."
The use of "just" was in simply comparing the difficulty of writing an internal save-state scheme to capture and record every emulated hardware object and maintain that code across new hardware additions/bugfixes/changes, vs. an unknown amount of effort to fix what might be a simple issue that nobody's mentioned since around 2010 according to forum search.
It seemed reasonable that the latter might be easier than the former, and that compatibility in general had improved enough in the last seven years to make it worth investigating again.
This does clarify the issue quite a bit for me, though, so thanks for the more detailed data. I'll report back on whether "real dos" has any impact on GW's behaviour with save states.