Subj : docs/v322_new.md src/sbbs3/ctrl/build.bat src/sbbs3/jsexec.vcxproj nts
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Windows 11)
Date : Fri Jul 17 2026 03:05:44

https://gitlab.synchro.net/main/sbbs/-/commit/9fc5505cbc4dfc9aeaab00ff
Modified Files:
	docs/v322_new.md src/sbbs3/ctrl/build.bat src/sbbs3/jsexec.vcxproj ntsvcs.vcxproj sbbscon.vcxproj
Log Message:
Windows: build all 32-bit Synchronet hosts /LARGEADDRESSAWARE

Mark sbbs.exe (sbbscon.vcxproj), sbbsNTsvcs.exe (ntsvcs.vcxproj),
jsexec.exe (jsexec.vcxproj), and sbbsctrl.exe (ctrl/build.bat) as
large-address-aware, raising their usable address space from 2GB to
~4GB on 64-bit Windows.

This is a stopgap for GitLab #1185: an access violation in mozjs185
seen only on 32-bit Windows under JS heap pressure (a web-scrape
attack), never on Linux-x64.  It raises the ceiling; it does not fix
the underlying pointer corruption, which the SM128 / 64-bit migration
addresses properly.

The MSVC projects get <LargeAddressAware>true</LargeAddressAware> in
both Debug|Win32 and Release|Win32 link steps.  Borland's ilink32 has
no LAA option, so build.bat flips the PE-header bit post-build
instead.

Validated: the 2006-era Borland host runs stably under LAA with
system-wide top-down allocation (Synchronet DLLs executing above 2GB,
all servers listening, no errors), and jsexec exercised the mozjs GC
and trace-JIT with ~3.4GB live above 2GB without failure.  Sustained
behavior under real scrape load is not yet proven.

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

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

.