VOGONS


First post, by keenerb

User metadata
Rank Oldbie
Rank
Oldbie

I've come across a few old posts that refer to missing system tables and other weirdness that keep the state saving from working. Has anyone looked into patching out the GW code that's failing, or adding dummy support code to Dosbox to fake whatever it's trying to save/reload?

It'd be really nice if this feature worked, and it IS technically a gaming-related problem, right?

Reply 1 of 4, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

You can't just patch around it or fake it if you want the restoring of saved state to actually work.

There is a chance GW32 save states will work if you boot real DOS in DOSBox. Another option is to forget about GW32 and use an unofficial build of DOSBox with the experimental save state patch. No guarantees with either choice.

Reply 2 of 4, by keenerb

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for the quick reply.

I'd love to have an "official" sort of fix for it so that it'll eventually be pushed out to the downstream forks and whatnot. Unofficial save state patch forks seem to be REALLY iffy in my experience, and this wouldn't necessarily be a major ongoing support issue, it'd just be fixing whatever's keeping this one single app from working.

I'll try with a "real dos" build, though.

Reply 3 of 4, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
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) used 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.

Reply 4 of 4, by keenerb

User metadata
Rank Oldbie
Rank
Oldbie
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.