Replace hardcoded C:\tinymux paths with MuxDir/Pcre2Dir derived from
MSBuildProjectDirectory so checkouts at tinymux-213 or elsewhere cannot
silently compile against another tree's PCRE2. Covers netmux, libmux,
engine, comsys, mail, exp3, sqlproxy, sqlslave. 2.13 half was #2187.
Every BOM in the tree, and an .editorconfig so Visual Studio does not put
them back.
All eleven carry no information: none of the files contains a single
non-ASCII byte, so the BOM was the only non-ASCII content in each.
Visual Studio wrote them when it generated or last touched those project
files. Ten are .vcxproj.filters; two are the sqlproxy and sqlslave
.vcxproj, which is why the /utf-8 commit had to restore them mid-change.
The concern that makes this worth more than tidying: Visual Studio adds a
signature when it needs to represent a non-ASCII character in a file that
had none. These files are pure ASCII, so removing the BOM should stick --
VS preserves the encoding it finds. But #1499 step 2 converts source
prose from \xE2\x80\x99 escapes to characters, which is precisely the
condition that starts making VS write signatures, and on .cpp rather than
on project files.
.editorconfig is the lever for that. charset = utf-8 means UTF-8 WITHOUT
a BOM (utf-8-bom is the spelling for with), and Visual Studio honours it,
as do VS Code, CLion and Sublime. It is deliberately the only key set:
indentation, line endings and trailing whitespace are left to existing
practice and CLAUDE.md, so the file cannot reformat anything by surprise.
Git cannot do this job, which is worth recording because it is the
obvious place to look. core.autocrlf is line endings only, and
.gitattributes' working-tree-encoding converts encodings rather than
stripping a signature -- pointing it at UTF-16 would ADD one. Stripping
a BOM through git needs a custom clean filter that every clone has to
configure locally; an .editorconfig needs no setup and acts where the BOM
is actually introduced.
A BOM is harmless to MSVC and tolerated by gcc and clang, so this is not
a correctness fix for compiled sources. It matters for files that are
executed rather than compiled -- a shell script or a .mux corpus file
with a BOM simply does not work -- and for keeping diffs free of churn
that depends on who last opened a file in an IDE.
Verified: full rebuild of all eleven projects clean, including the two
whose .vcxproj lost its BOM; smoke 316 dispatched, 1487 succeeded, 17
failed (the known build-configuration failures here); format, netaddr and
alarm harnesses pass; zero BOMs left in any tracked file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Step 1 of #1499, the behaviour-neutral half. Adds /utf-8 to all eleven
vcxproj files and to the two MSVC builder scripts, so source and
execution charset are both UTF-8 instead of the system code page.
Verified neutral rather than asserted. Built the tree twice on the same
box, with and without the flag, and diffed the extracted string tables:
netmux.exe 1 differing line
engine.dll 1 differing line
libmux.dll 0 differing lines
Every one of those is binary noise at a shifted address that happens to
match a UTF-8 lead-byte pattern; the only human-readable difference in
the whole comparison is engine.dll's __DATE__/__TIME__ stamp. No string
literal changes, and the U+2019 counts are identical (netmux 5,
engine 175, libmux 1), as are the file sizes.
Also measured why the escapes exist, because it is not what I expected.
On this box the active code page is 1252, and raw UTF-8 in a narrow
literal survives WITHOUT the flag -- all six typographic characters from
the issue's table round-trip byte-for-byte, including U+201D, whose 0x9D
is undefined in CP1252. So "it works here" would have been a misleading
result to report.
The flag matters on a DBCS locale. Compiling the same file as a
Japanese-locale box would:
cl /source-charset:.932 /execution-charset:.932
warning C4819: The file contains a character that cannot be
represented in the current code page (932)
error C2001: newline in string literal
It does not mangle quietly -- it fails to compile, because the UTF-8
bytes are read as Shift-JIS lead bytes and swallow the closing quote.
With /utf-8 on that same simulated locale, correct. That is the real
constraint the hex escapes were working around, and this removes it.
Step 2 (converting escapes to characters) is deliberately not here. It
should follow only once this is in and verified, exactly as the issue
sequences it.
Smoke: 316 dispatched, 1487 succeeded, 17 failed -- the known
build-configuration failures on this box. format, netaddr and alarm
harnesses all pass. No C4819 anywhere in the build.
Two vcxproj files (sqlproxy, sqlslave) carry a UTF-8 BOM; my first pass
stripped it and I put it back, so the diff is 22 insertions and no
deletions.
tests/dbt/build-msvc.sh needs the same flag and is not in this commit --
it is still in review as #1493.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The modular architecture (netmux.exe, libmux.dll, engine.dll, etc.)
with static CRT (/MT) gave each module its own CRT heap. FILE* handles
from mux_fopen (in libmux) crashed when used by stdio functions in
other modules — fclose in write_pidfile, fgets in cf_include, etc.
Switch all 11 vcxproj files to /MD (shared CRT DLL) so all modules
share one CRT instance. Ship msvcp140.dll, vcruntime140.dll, and
vcruntime140_1.dll in the binary distribution.
Also add mux_fclose to libmux as good hygiene (pairs with mux_fopen),
and replace all cross-module fclose calls. This change is safe on Unix
where everything links into one process.
Add Startmux.bat as a replacement for Startmux.wsf since Windows
Script Host is no longer associated by default on modern Windows.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Remove all autoconf-win32.h from ClInclude (template, not a project header)
- Remove empty Resource Files filter groups from ganl, libmux, sqlproxy,
sqlslave, netmux
- libmux.vcxproj.filters: update all paths to lib\ and include\ prefixes
to match actual source layout
- netmux.vcxproj.filters: rewrite entirely — trim to the slim driver
sources (src\) and headers (include\) that netmux actually compiles
- sqlproxy/sqlslave filters: fix header paths from stale ..\ to
correct ..\..\include\
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
