https://gitlab.synchro.net/main/sbbs/-/commit/bae2a09d5c42b9cc9ad703f4
Modified Files:
src/doors/syncscumm/msvc/Directory.Build.targets
Log Message:
syncscumm: fix door crash on game save (Windows zlib link conflict)

Saving a game dropped the caller straight back to the BBS: the door FAST_FAIL-aborted. The crash dump showed abort() from the
assert(_zlibErr == Z_OK) in ScummVM's GZipWriteStream ctor (common/compression/zlib.cpp), reached via ScummEngine::saveState -> openSaveFileForWriting -> DefaultSaveFileManager::openForSaving -> wrapCompressedWriteStream -- i.e. deflateInit2() (the savegame gzip
compressor) returned non-Z_OK.

Root cause: the Win32 link contained TWO zlibs. libjpeg-turbo's
turbojpeg.lib vendors its own copy (it defines _deflateInit2_,
_inflate, _zlibVersion, ...), and vcpkg auto-links the whole prefix
with an alphabetical lib\*.lib wildcard, so turbojpeg.lib preceded
zs.lib (the real zlib 1.3.2 the engine compiled against). MSVC bound
the engine's deflateInit2 to turbojpeg's copy, which rejects ScummVM's gzip-mode parameters (windowBits = MAX_WBITS + 16) with Z_STREAM_ERROR
while real zlib returns Z_OK. Proven in isolation: linking
turbojpeg.lib first -> deflateInit2 == -2; zs.lib first -> 0.
Windows-only; the *nix build links one system zlib.

Fix: list zs.lib ahead of the vcpkg wildcard in the scummvm project's
link inputs, so the engine's zlib calls bind to the matching zlib. The
door never uses the TurboJPEG API (ScummVM uses classic jpeg.lib), so turbojpeg.lib is only collateral. This broke every SyncSCUMM title's
save on Windows, not just one.

Introduced by the initial Win32/MSVC build in 745c1c542b
(monthly-47-hole); *nix was never affected.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net