Even though strcpy in SegManager isn't a problem, our forbidden symbols
list being defined at preprocessor level, we won't be able to use this
name anymore.
In GK2, restoring a save game causes the segment manager to reset
in the middle of a kListFirstTrue call, which invalidates all
pointers and reg_ts to stored data. This means that when
kListFirstTrue tries to decrement the list recursion counter at
the end of iteration, it is writing to freed memory, potentially
resulting in heap corruption.
SCI3 added checks to prevent this from happening, but these checks
seem like they should have also been applied to some SCI2.1 games
as well (like GK2).
Since there should be no negative side-effect to this check, it
is applied universally to all SCI32 games.
This change invalidates earlier SCI32 save games, which separated
arrays and strings in an incompatible manner. Old save games
contain invalid references to a string segment which no longer
exists, and contain incompatible array structures that lack
critical type information.
Bitmaps in ScrollWindow and Robot code are managed by the kernel
and not by game scripts, although they must be able to be
referenced through a reg_t. To prevent incorrect GC of bitmaps
that are in use but not referenced by any game script, explicit
memory management of hunk entries can be enabled.
When resetting the segment manager, sometimes the locals block for a
script is placed in a segment smaller than the script itself. This
shouldn't be happening, but it isn't fatal, however it should be resolved
in a proper manner
- Maintain the state of the string heap space in saved games
- Merged SegManager::reconstructScripts() inside SegManager::saveLoadWithSerializer()
- Disabled a now unnecessary script patch for the cipher puzzle in Castle of Dr. Brain, and performed some cleanup for another disabled patch
- Removed direct access to the _baseObj variable of objects
svn-id: r54133
This require a small tweak to the save/load code: I moved the syncing
logic for _classtable from EngineState::saveLoadWithSerializer to
SegManager::saveLoadWithSerializer, which in theory should have no
effect (luckily, _classtable was being synced right after the
segment manager).
svn-id: r50551