tinymux/mux/modules/sqlproxy/sqlproxy.vcxproj

137 lines
6.5 KiB
XML
Raw Permalink Normal View History

build: remove the 11 UTF-8 BOMs, and stop editors re-adding them (#1499) 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>
2026-07-26 21:20:02 -06:00
<?xml version="1.0" encoding="utf-8"?>
2018-06-03 02:10:04 -06:00
<Project DefaultTargets="Build" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
2018-05-31 15:37:39 -06:00
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Debug|x64">
<Configuration>Debug</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
<ProjectConfiguration Include="Release|x64">
<Configuration>Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{5689B87D-E634-4061-8090-BC93974ABB2E}</ProjectGuid>
<WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
2018-05-31 15:37:39 -06:00
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<PlatformToolset>v145</PlatformToolset>
2018-05-31 15:37:39 -06:00
<UseOfMfc>false</UseOfMfc>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<PlatformToolset>v145</PlatformToolset>
2018-05-31 15:37:39 -06:00
<UseOfMfc>false</UseOfMfc>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="ExtensionSettings">
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
</ImportGroup>
<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="PropertySheets">
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<_ProjectFileVersion>12.0.30501.0</_ProjectFileVersion>
<!-- #2185: relative to mux\modules\sqlproxy\ -->
<MuxDir Condition="'$(MuxDir)' == ''">$(MSBuildProjectDirectory)\..\..</MuxDir>
2018-05-31 15:37:39 -06:00
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
Rework Windows build for component-based directory layout Adapt all vcxproj files and solution to the new directory structure (src/ driver, lib/ shared library, modules/engine/ game logic, modules/{comsys,mail,exp3,sqlproxy,sqlslave}/ loadable modules). Key changes: - libmux.dll exports utility symbols via LIBMUX_API macro (__declspec(dllexport) when BUILDING_LIBMUX, dllimport otherwise) - LIBMUX_API added to all shared headers: stringutil.h, timeutil.h, mathutil.h, utf8tables.h, svdhash.h, svdrand.h, sha1.h, alloc.h, dbutil.h, core.h - Per-file PreprocessorDefinitions in libmux.vcxproj inherit from project-level via %(PreprocessorDefinitions) - Driver factory declarations (CDriverControlFactory, CConnectionManagerFactory) guarded with BUILDING_DRIVER - PCG-XSH-RR-64/32 (pcg32) for Windows (no __int128 needed); Unix PCG-XSL-RR-128/64 unchanged - MSVC portability fixes: _strnicmp, _BitScanForward64, (std::min)(), HAVE_WORKING_FORK guards, WINDOWS_FILES/UNIX_FILES ModuleAdd paths - Remove stubslave.cpp and slave.cpp from netmux.vcxproj (separate processes) - Fix sqlproxy/sqlslave vcxproj relative paths for new layout - Add ws2_32.lib to engine.vcxproj for socket functions - Add strcasecmp/strtok_r/strndup compat shims for comsys/mail Builds successfully: libmux.dll, engine.dll, netmux.exe, exp3.dll, sqlproxy.dll, sqlslave.dll. Comsys/mail blocked on sqlite3 linking architecture (need COM-mediated or independent sqlite3 linkage). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-10 09:38:57 -06:00
<OutDir>..\..\bin_release\</OutDir>
<IntDir>$(Platform)\$(Configuration)\$(ProjectName)\</IntDir>
<IncludePath>$(MuxDir)\include;$(IncludePath)</IncludePath>
2018-05-31 15:37:39 -06:00
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
Rework Windows build for component-based directory layout Adapt all vcxproj files and solution to the new directory structure (src/ driver, lib/ shared library, modules/engine/ game logic, modules/{comsys,mail,exp3,sqlproxy,sqlslave}/ loadable modules). Key changes: - libmux.dll exports utility symbols via LIBMUX_API macro (__declspec(dllexport) when BUILDING_LIBMUX, dllimport otherwise) - LIBMUX_API added to all shared headers: stringutil.h, timeutil.h, mathutil.h, utf8tables.h, svdhash.h, svdrand.h, sha1.h, alloc.h, dbutil.h, core.h - Per-file PreprocessorDefinitions in libmux.vcxproj inherit from project-level via %(PreprocessorDefinitions) - Driver factory declarations (CDriverControlFactory, CConnectionManagerFactory) guarded with BUILDING_DRIVER - PCG-XSH-RR-64/32 (pcg32) for Windows (no __int128 needed); Unix PCG-XSL-RR-128/64 unchanged - MSVC portability fixes: _strnicmp, _BitScanForward64, (std::min)(), HAVE_WORKING_FORK guards, WINDOWS_FILES/UNIX_FILES ModuleAdd paths - Remove stubslave.cpp and slave.cpp from netmux.vcxproj (separate processes) - Fix sqlproxy/sqlslave vcxproj relative paths for new layout - Add ws2_32.lib to engine.vcxproj for socket functions - Add strcasecmp/strtok_r/strndup compat shims for comsys/mail Builds successfully: libmux.dll, engine.dll, netmux.exe, exp3.dll, sqlproxy.dll, sqlslave.dll. Comsys/mail blocked on sqlite3 linking architecture (need COM-mediated or independent sqlite3 linkage). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-10 09:38:57 -06:00
<OutDir>..\..\bin_debug\</OutDir>
<IntDir>$(Platform)\$(Configuration)\$(ProjectName)\</IntDir>
<IncludePath>$(MuxDir)\include;$(IncludePath)</IncludePath>
2018-05-31 15:37:39 -06:00
</PropertyGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<Midl>
<PreprocessorDefinitions>NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MkTypLibCompatible>true</MkTypLibCompatible>
<SuppressStartupBanner>true</SuppressStartupBanner>
<TargetEnvironment>X64</TargetEnvironment>
<TypeLibraryName>.\bin_release/sqlproxy.tlb</TypeLibraryName>
<HeaderFileName />
</Midl>
<ClCompile>
build(win32): add /utf-8 to the MSVC projects (#1499) 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>
2026-07-26 20:58:42 -06:00
<AdditionalOptions>/utf-8 %(AdditionalOptions)</AdditionalOptions>
2018-05-31 15:37:39 -06:00
<Optimization>Full</Optimization>
<InlineFunctionExpansion>OnlyExplicitInline</InlineFunctionExpansion>
<IntrinsicFunctions>true</IntrinsicFunctions>
<FavorSizeOrSpeed>Speed</FavorSizeOrSpeed>
<PreprocessorDefinitions>WIN32;NDEBUG;UNICODE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>
2018-05-31 15:37:39 -06:00
<PrecompiledHeader />
<CallingConvention>FastCall</CallingConvention>
<LanguageStandard>stdcpp17</LanguageStandard>
2018-05-31 15:37:39 -06:00
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>NDEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<Culture>0x0409</Culture>
</ResourceCompile>
<Link>
<ModuleDefinitionFile />
<SubSystem>Windows</SubSystem>
<RandomizedBaseAddress>true</RandomizedBaseAddress>
2018-05-31 15:37:39 -06:00
<DataExecutionPrevention />
<TargetMachine>MachineX64</TargetMachine>
</Link>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<Midl>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MkTypLibCompatible>true</MkTypLibCompatible>
<SuppressStartupBanner>true</SuppressStartupBanner>
<TargetEnvironment>X64</TargetEnvironment>
<TypeLibraryName>.\bin_debug/sqlproxy.tlb</TypeLibraryName>
<HeaderFileName />
</Midl>
<ClCompile>
build(win32): add /utf-8 to the MSVC projects (#1499) 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>
2026-07-26 20:58:42 -06:00
<AdditionalOptions>/utf-8 %(AdditionalOptions)</AdditionalOptions>
2018-05-31 15:37:39 -06:00
<PreprocessorDefinitions>WIN32;_DEBUG;UNICODE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<RuntimeLibrary>MultiThreadedDebugDLL</RuntimeLibrary>
2018-05-31 15:37:39 -06:00
<PrecompiledHeader />
<LanguageStandard>stdcpp17</LanguageStandard>
2018-05-31 15:37:39 -06:00
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<Culture>0x0409</Culture>
</ResourceCompile>
<Link>
<ModuleDefinitionFile />
<SubSystem>Windows</SubSystem>
<DataExecutionPrevention />
<TargetMachine>MachineX64</TargetMachine>
</Link>
</ItemDefinitionGroup>
<ItemGroup>
<ClCompile Include="sqlproxy.cpp">
<Optimization Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">Disabled</Optimization>
<PreprocessorDefinitions Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">WIN32;_DEBUG;UNICODE</PreprocessorDefinitions>
<BasicRuntimeChecks Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">EnableFastChecks</BasicRuntimeChecks>
<Optimization Condition="'$(Configuration)|$(Platform)'=='Release|x64'">Full</Optimization>
<PreprocessorDefinitions Condition="'$(Configuration)|$(Platform)'=='Release|x64'">WIN32;NDEBUG;UNICODE</PreprocessorDefinitions>
</ClCompile>
</ItemGroup>
<ItemGroup>
Rework Windows build for component-based directory layout Adapt all vcxproj files and solution to the new directory structure (src/ driver, lib/ shared library, modules/engine/ game logic, modules/{comsys,mail,exp3,sqlproxy,sqlslave}/ loadable modules). Key changes: - libmux.dll exports utility symbols via LIBMUX_API macro (__declspec(dllexport) when BUILDING_LIBMUX, dllimport otherwise) - LIBMUX_API added to all shared headers: stringutil.h, timeutil.h, mathutil.h, utf8tables.h, svdhash.h, svdrand.h, sha1.h, alloc.h, dbutil.h, core.h - Per-file PreprocessorDefinitions in libmux.vcxproj inherit from project-level via %(PreprocessorDefinitions) - Driver factory declarations (CDriverControlFactory, CConnectionManagerFactory) guarded with BUILDING_DRIVER - PCG-XSH-RR-64/32 (pcg32) for Windows (no __int128 needed); Unix PCG-XSL-RR-128/64 unchanged - MSVC portability fixes: _strnicmp, _BitScanForward64, (std::min)(), HAVE_WORKING_FORK guards, WINDOWS_FILES/UNIX_FILES ModuleAdd paths - Remove stubslave.cpp and slave.cpp from netmux.vcxproj (separate processes) - Fix sqlproxy/sqlslave vcxproj relative paths for new layout - Add ws2_32.lib to engine.vcxproj for socket functions - Add strcasecmp/strtok_r/strndup compat shims for comsys/mail Builds successfully: libmux.dll, engine.dll, netmux.exe, exp3.dll, sqlproxy.dll, sqlslave.dll. Comsys/mail blocked on sqlite3 linking architecture (need COM-mediated or independent sqlite3 linkage). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-10 09:38:57 -06:00
<ClInclude Include="..\..\include\config.h" />
<ClInclude Include="..\..\include\libmux.h" />
<ClInclude Include="..\..\include\modules.h" />
<ClInclude Include="..\..\include\sql.h" />
2018-05-31 15:37:39 -06:00
</ItemGroup>
<ItemGroup>
Rework Windows build for component-based directory layout Adapt all vcxproj files and solution to the new directory structure (src/ driver, lib/ shared library, modules/engine/ game logic, modules/{comsys,mail,exp3,sqlproxy,sqlslave}/ loadable modules). Key changes: - libmux.dll exports utility symbols via LIBMUX_API macro (__declspec(dllexport) when BUILDING_LIBMUX, dllimport otherwise) - LIBMUX_API added to all shared headers: stringutil.h, timeutil.h, mathutil.h, utf8tables.h, svdhash.h, svdrand.h, sha1.h, alloc.h, dbutil.h, core.h - Per-file PreprocessorDefinitions in libmux.vcxproj inherit from project-level via %(PreprocessorDefinitions) - Driver factory declarations (CDriverControlFactory, CConnectionManagerFactory) guarded with BUILDING_DRIVER - PCG-XSH-RR-64/32 (pcg32) for Windows (no __int128 needed); Unix PCG-XSL-RR-128/64 unchanged - MSVC portability fixes: _strnicmp, _BitScanForward64, (std::min)(), HAVE_WORKING_FORK guards, WINDOWS_FILES/UNIX_FILES ModuleAdd paths - Remove stubslave.cpp and slave.cpp from netmux.vcxproj (separate processes) - Fix sqlproxy/sqlslave vcxproj relative paths for new layout - Add ws2_32.lib to engine.vcxproj for socket functions - Add strcasecmp/strtok_r/strndup compat shims for comsys/mail Builds successfully: libmux.dll, engine.dll, netmux.exe, exp3.dll, sqlproxy.dll, sqlslave.dll. Comsys/mail blocked on sqlite3 linking architecture (need COM-mediated or independent sqlite3 linkage). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-10 09:38:57 -06:00
<ProjectReference Include="..\..\libmux.vcxproj">
2018-05-31 15:37:39 -06:00
<Project>{fea073c1-4f18-42a1-ac39-1a2ec0a65e92}</Project>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
</Project>