https://gitlab.synchro.net/main/sbbs/-/commit/88cf67b5761d0cff1c95aa76
Modified Files:
exec/load/syncretro_lobby.js
Log Message:
syncretro lobby: pass the ROM relative to the door directory

The door command line is assembled by the BBS into a buffer that truncates silently at 260 characters, and the ROM is the LAST argument on it -- so the ROM is what disappears when the line overflows, producing a door that reports its content missing while the BBS log shows that content's full path.

Passing "roms\pacman.zip" instead of "s:\sbbs\xtrn\syncarcade\roms\pacman.zip" gives 24 characters back, taking a SyncArcade line from ~240 to ~216 and roughly doubling the margin. That covers a long game title: "1943: The Battle of Midway" costs 19 characters more than "Pac-Man" and previously came within
a few bytes of the cliff.

Safe because the BBS starts the door IN the door's directory -- Synchronet passes startup_dir to CreateProcess as the working directory on Windows and chdir()s to it before exec on *nix -- and sr_resolve_file() tries the name as-given (against that cwd) before absolutizing, all of it before the door chdir()s into the per-user sandbox. It is not a new dependency: the door already locates syncretro.ini, its core and its BIOS relative to the same
cwd, so a door started elsewhere could not run at all.

Built from rules.dir rather than a hardcoded "roms" so a sysop who moves the ROM directory keeps working -- the lobby names the directory it actually scanned, which also side-steps the door's own bare-name fallback being hardcoded to roms/.

Verified against the installed door: galaga, dkong and mspacman all load from
a relative argument, and the derived content path is identical to the absolute form's.

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