tinymux/win32/TOC.bin.patchable
Stephen Dennis 6cccafd1d0 fix(win32): no module could load under muxscript, for two reasons (#1594)
The module preflight added with #1572 turned master red on Windows because
none of the three modules smoke.conf configures could load there.  Two
independent causes; fixing either alone left the run red.

1. comsys and mail built as comsys.dll / mail.dll, while modules/Makefile.am
   builds comsys_mod.so / mail_mod.so.  `cf_module` resolves `module <name>`
   to `.\bin\<name>.dll` or `./bin/<name>.so`, so no single config line could
   name those two modules on both platforms.  The vcxproj files were taking
   their default TargetName; they now set it explicitly.  Renaming the
   Windows side rather than the Unix side because those two DLLs had no
   DCL_EXPORT until #1569 and so were never loadable on Windows at all --
   nothing can depend on the old names, whereas Unix installs use _mod today.

2. exp3 -- whose name already matched on both platforms -- still did not
   load, silently, and only under muxscript.  LoadLibrary() does not treat a
   relative path as relative to the current directory: it appends the whole
   relative path to every entry in the DLL search order.  The current
   directory is one of those entries until something calls SetDllDirectory(),
   which removes it.  muxscript calls it in init_com() so engine.dll can find
   libmux.dll, and cf_module hands LoadLibrary ".\bin\<name>.dll" -- so under
   muxscript that resolved nowhere.  netmux never calls SetDllDirectory(),
   which is why the identical config worked there and the divergence looked
   inexplicable.  ModuleLoad now resolves the path against the current
   directory itself, which is what every caller already assumed.

Both smoke gates go back to unconditional.  They were made advisory on
Windows only because the platform could not comply; it can now.

Verified on Windows Server 2022, MSVC 14.51, Release x64: all three modules
report (loaded) under muxscript from a clean environment, netmux logs
"Comsys module loaded" / "Mail module loaded" with the new names, and the
preflight passes silently in the smoke run.

Measured, and worth recording for #1589/#1614: with the modules finally live
on Windows, the suite returns exactly what it returns without them --
1555 succeeded, 5 failed, same five, same one-verdict deficit.  The five are
a pre-existing configuration gap (autoconf-win32.h has no HAVE_LIBSSL and no
reality levels), not a regression, and they are identical with
SMOKE_OMIT_MODULES set.  The corpus still cannot tell the two
implementations apart.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-27 18:46:23 -06:00

49 lines
827 B
Text

ALPHA.md
ATTACK.md
BETA.md
CHANGES.md
docs/BACKUPS.md
docs/CONFIGURATION.md
docs/CREDITS.md
docs/DISTRIBUTIONS.md
docs/GUESTS.md
docs/HISTORY.md
docs/LIMITS.md
docs/PATCHES.md
docs/REALMS.md
game/alias.conf
game/bin/comsys_mod.dll
game/bin/engine.dll
game/bin/exp3.dll
game/bin/libmux.dll
game/bin/mail_mod.dll
game/bin/msvcp140.dll
game/bin/muxscript.exe
game/bin/netmux.exe
game/bin/pcre2-8.dll
game/bin/softlib.rv64
game/bin/sqlproxy.dll
game/bin/sqlslave.dll
game/bin/vcruntime140.dll
game/bin/vcruntime140_1.dll
game/compat.conf
game/data/db_load.bat
game/data/db_unload.bat
game/Startmux.bat
game/Startmux.wsf
game/text/connect_help.txt
game/text/help.txt
game/text/wizhelp.txt
include/copyright.h
INSTALL.md
LOCAL.md
MODULES.md
NOTES.md
README.md
readme.txt
REALITY.md
REALITY.SETUP.md
SGP.md
SQL.md
SSL.md
UPGRADING.md