Frame pointers on: dbghelp's stack walker gets usable frames in crash
reports. /Oy- rather than -fno-omit-frame-pointer -- clang-cl rejects
the GNU spelling:("unknown argument ignored"), and cl.exe takes /Oy-
too. x86-only option; a 64-bit target would ignore it and rely on
unwind data instead.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
OBJECTTYPE::exists() and SOLDIERTYPE::exists()/DeleteSoldier() are
called on null pointers by design and guard with `this == NULL`. That
is undefined behaviour, so clang infers `this` is non-null: it deletes
the guard inside the callee *and* deletes null checks that follow a
call in the caller, which is an access violation at /O2 in code MSVC
has always compiled the naive way. The caller-side inference happens
in every translation unit that calls one of these, so this has to be
global rather than per-file; there is no per-function attribute or
pragma for it. Drop it once nothing relies on a null `this`.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds tools/symbolize_crash.cpp, built alongside the game as a console exe:
it reads a crash_report_*.txt written by writeExceptionBacktrace and prints
the backtrace with function names, source lines and inlined frames, in call
order, coloured when standard output is a console.
Symbols come from DbgHelp against the build's PDB rather than an external
symbolizer. SymLoadModuleEx takes the runtime base out of the report's
module table, so the relocation arithmetic /DYNAMICBASE forces on us is
DbgHelp's problem now; a report predating the module table loads at the
image's preferred base, which is where it ran. Verified under Wine: PDB
line info and inline traces both resolve.
The tool wants C++23 (std::print, std::format) where the game is C++17, so
the standard is set on the target alone. Both MSVC 19.51 and clang-cl build
it clean in all three configurations.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A crash report is worth nothing sitting on the player's disk. On startup, drain
the crash_report_*.txt files the handler left behind to the endpoint named by
CRASH_TELEMETRY_URL in Ja2 Settings; an empty or absent key turns the feature off
entirely. The first launch asks the player once and remembers the answer in
telemetry.consent -- declined means the reports simply keep accumulating locally.
This lands in its own translation unit rather than in more of debug_win_util.cpp.
Everything in that file runs inside a faulting thread and may not allocate;
everything here runs at startup with a healthy heap and is ordinary code. Two
files keep the no-heap rule easy to see and easy to hold.
The draining runs on a detached thread. The uploads are synchronous WinHttp calls
with seconds-long timeouts, and this sits on the startup path, so on the main
thread an unreachable endpoint is a stall the player watches before the splash
screen. Nothing waits on the result: if the player quits first the process exits
from under the thread, which costs nothing, since an interrupted upload leaves the
file on disk and it goes out next launch. The consent prompt stays on the main
thread on purpose -- it is a question, and a question has to be asked before
anything is sent.
Which reports get deleted is chosen so that a mistake cannot destroy them. A file
goes away on 2xx, and on 400/413/415, i.e. content the server will never accept.
Everything else keeps it: no connection, 5xx, and notably the 403/404 of a
mistyped CRASH_TELEMETRY_URL, which would otherwise silently eat every player's
crash history. Bounds all round: every WinHttp phase has a timeout, a report over
256 KB is not one of ours and never goes on the wire, at most 20 uploads per
launch so a crash-looping build cannot turn startup into an upload session, and
reports older than 30 days are dropped unsent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
binkw32.lib as shipped is a long-format ordinal import library built in
2002, and link.exe is the only linker left that binds it. lld-link takes
it without complaint and writes an import descriptor with an empty thunk
table, so every Bink call reaches whatever the stale IAT slot holds. The
first one is BinkSoundUseDirectSound, reached from BinkInitialize during
EnterIntroScreen, which is unconditional -- Intro.cpp constructs its
VideoPlayer with VT_SMK|VT_BINK in every application, so a Smacker-only
gamedir still runs the Bink init path. The process dies before the splash
with an access violation executing an unmapped address.
clang-cl.cmake and mingw.cmake already rebuilt the library from
binkw32.def for exactly this reason, but they are toolchain files, so the
rebuild only happened when someone cross-compiled. Which linker is in use
is not a cross-compilation question: a preset that points
CMAKE_CXX_COMPILER at clang-cl -- how you use it from Visual Studio --
loads no toolchain file and linked the broken library instead. The test
was a proxy for "is this lld-link", correct until it wasn't.
So the rebuild moves to the top-level CMakeLists and runs unconditionally,
and clang-cl.cmake loses its copy: it already sets CMAKE_AR to llvm-lib,
which is the same binary the new code invokes with the same arguments.
mingw.cmake keeps its own, because GNU ar cannot build an import library
at all and dlltool takes different flags.
Only the name shape differs between archivers. lib.exe prepends the x86
leading underscore to every name in the .def; llvm-lib and llvm-dlltool
take the name as written. The checked-in file keeps the underscore for the
llvm tools and the MSVC path strips it back off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
No warning is fixed here. Every one we currently emit is harvested and
switched off one by one, and /WX goes on top, so both toolchains build
quiet and any *new* warning fails the build instead of scrolling past.
cmake/Warnings.cmake carries two independent lists, one per compiler,
one line per warning with its occurrence count. Deleting a single line
is the unit of work from here on: drop the line, fix the fallout in
both compilers, commit. The build stays honest in the meantime.
Picking a level had to come first. CMake stopped injecting /W3 of its
own accord (policy CMP0092), which had quietly left MSVC on the /W1
default and hid nearly everything; at /W4 it reports 89361 warnings
across 31 codes. clang-cl is pinned to /W3 -- clang's own -Wall, and
already broader than MSVC /W4 -- for 55 more. The two lists are not
comparable by length.
Counts cover all four applications, since the #ifdef forest means each
one compiles different code. The file is included after the ext/
subdirectories so that add_compile_options' directory scope leaves
vendored code on its default flags; ext/ still warns, deliberately,
and /WX does not reach it.
The existing /wd4838 moves here with the rest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The tree compiles and links under clang-cl, so make that a configuration
anyone can ask for rather than a command line to reconstruct:
MSVC_DIRECTORY=/path/to/msvc cmake --preset '1dot13 Release clang-cl'
It is a check on the source, not a port -- MSVC still builds what ships. What
it buys is a second front end over every translation unit, which is how the
inline assembly with no operand size and the resource string with a raw 0xA9
were found, and it runs natively: clang-cl, lld-link, llvm-rc and llvm-lib
need no Wine, so a full JA2.exe takes a fraction of the time.
The toolchain file names every MSVC and SDK include directory, because
clang-cl does not read INCLUDE and LIB the way cl does, and picks the newest
version of each tree rather than pinning one. MSVC_DIRECTORY says where they
live and is reported plainly when it is missing or wrong.
build a bindable Bink import library when not building with MSVC
The shipped binkw32.lib is an old ordinal-based long-format import library.
MSVC's link.exe binds it, but clang-cl's lld-link does not: it leaves every
Bink import unresolved, so at run time the calls jump into arbitrary code and
crash the game at startup, six access violations deep in unrelated code before
the game's own handler gives up.
Rebuild the import library from binkw32.def with llvm-dlltool on any front end
other than MSVC. The library imports by ordinal, for the reasons binkw32.def
records: binkw32.dll exports decorated stdcall names that keep their leading
underscore (_BinkOpen@8), and llvm-dlltool strips that underscore from the
imported name whatever --no-leading-underscore says, so a by-name import would
look up a name the DLL does not export and Wine would substitute a builtin stub
that aborts ("unimplemented function binkw32.dll.BinkSetSoundSystem@8").
Ordinals have no such ambiguity and match the retail DLL. MSVC keeps binding the
shipped library, so the retail build is untouched.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
refactor toolchain
make the preset template something CMake will read
The template carries two // comments. JSON has no comments and neither does
the preset format, so CMake refuses the whole file:
CMakePresets.json:10: Missing '}' or object member name
Which means the file CopyUserPresetTemplate drops into the source directory
has never worked as handed over -- "cmake --preset '1dot13 Release'" fails
until you delete the comments yourself.
The text they carried is worth keeping, so it moves to the description field
the format does have, and cmake --preset '1dot13 Release' now configures.
Two link settings were conditional on the Visual Studio generator, though
what they compensate for is the prebuilt libraries in the tree, which are the
same libraries under every generator. Ninja builds got away with it because
link.exe is quiet about both; lld-link is not.
legacy_stdio_definitions.lib: RakNetLibStatic.lib still calls _vsnprintf,
which the UCRT only exports through that compatibility library.
/SAFESEH:NO: lua51.lib and the smackw32 import library carry no safe
exception handler table, so no linker can emit one. The image never had it.
Before and after, JA2.exe reports SEHandlerTable 0x0 and SEHandlerCount 0,
with DYNAMIC_BASE, NX_COMPAT and TERMINAL_SERVER_AWARE unchanged -- the flag
states what link.exe was already doing silently.
Dbghelp.lib and Winmm.lib are also spelled as the SDK ships them, since a
cross-compile looks for them on a case sensitive filesystem.
Drops the last piece of the proprietary Smacker SDK: SMACKW32.LIB, its
header sgp/SMACK.H, and with them the SMACKW32.DLL the game needed at
runtime. Bink is untouched and still needs binkw32.
The two libraries divide the work differently, so Cinematics.cpp changes
more than the call names. SMACKW32.DLL played a file: it kept the playback
clock (SmackWait), blitted converted 16bpp pixels into a surface we handed
it (SmackToBuffer) and pushed the audio to DirectSound itself. libsmacker
only decodes, so this module now:
- keeps the clock. Frames are advanced against GetTickCount() from the
moment the flic starts, skipping frames if the game fell behind, which
is what SmackWait/SmackDoFrame did internally.
- blits itself. Frames come out 8bpp palettised, so the palette is
converted with Get16BPPColor() and the frame is written into the frame
buffer, clipped to the screen. The Y-scaling flags are not handled;
none of the videos shipping with the game set them.
- plays the audio itself, through the SoundPlayFromBuffer() added earlier.
libsmacker hands out audio a frame at a time, so the whole track is
decoded up front, with the video track disabled to keep that pass cheap,
and given a WAV header so the sound module can take it.
libsmacker reads from memory, which lets the file be read straight out of
the VFS. That removes the dance where the .smk was first copied to a real
file under Temp/ because SmackOpen() could only open a path.
SmkInitialize() loses its window and screen size arguments, which only
existed for SmackBufferOpen(). SmkOpenFlic(), SmkSetBlitPosition() and
SmkGetFreeFlic() are no longer declared in the header; nothing outside the
module called them. SMKFLIC is now opaque, Intro.cpp only holds pointers.
The unused SMACK.H include in Cinematics Bink.cpp goes away as well.
Tested by running the Sirtech splash screen (SPLASHSCREEN.SMK, 640x480,
15 fps, one 44.1kHz 16 bit stereo track) under Wine: picture, palette,
placement and playback speed are right.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
refactor
squashed into a single commit because doing it in steps that all
compiled involved a lot of boilerplate that is pointless to commit to
the repository. GH still has the PR for reference.
g_lang, MAX_MESSAGES_ON_MAP_BOTTOM, and GetLanguagePrefix() were
compile-time constants selected by the ENGLISH/GERMAN/... build
define. They're now runtime, defaulting to the same per-exe value the
define used to pick, and overridable at startup from [Ja2 Settings]
LANGUAGE in Ja2.ini.
-
XMLTacticalMessages is filled at runtime from NewTacticalMessages.xml,
never from compiled-in per-language data: all 8 per-language definitions
were the identical all-zero { L"" }. Delete them and define one shared
buffer in Utils/XML_Language.cpp (the loader) instead of pointer-rebinding
it like the static tables — this drops 9 dead 800KB zero-buffers (8
namespaced copies in LanguageStrings.cpp plus the standalone one) and
leaves no bind-ordering hazard for the XML load path.
-
ExportStrings.cpp privately recompiled one language's full text table
by #including the raw _<LANG>Text.cpp inside namespace Loc, keyed off
the exe-level ENGLISH/GERMAN/... compile macro (whichever the build
happened to select). That's redundant with the pointer globals every
other subsystem already uses (Text.h / LanguageStrings.cpp).
Drop the private copy; the unqualified table names in Loc::ExportStrings
now resolve to the global pointer externs, which BindLanguageStrings has
already rebound to the runtime g_lang by the time this runs (EXPORT_STRINGS
ini flag, checked after GetRuntimeSettings in sgp.cpp). gs_Lang (used only
by Loc::Translate for the Polish/Russian byte remap on raw .edt exports) is
now derived from g_lang via ToLocLanguage, so the export always matches
whatever language is actually active instead of a compile-time pick.
-
Editor/popupmenu.cpp and Strategic/Scheduling.cpp kept their own
call-site extern of gszScheduleActions as CHAR16[NUM_SCHEDULE_ACTIONS][20]
after the real definition changed into a rebindable pointer
(CHAR16 (*)[20], LanguageStrings.cpp). MSVC decays the outer array
dimension when mangling globals, so both declarations produce the same
symbol (?gszScheduleActions@@3PAY0BE@_WA) and the mismatch linked
silently -- but the array-typed TUs then indexed the 4-byte pointer
slot itself as string data, so the editor schedule popup and the map
schedule message text read garbage.
-
add text.def to be single-source of truth on symbol names and use it
.much simpler, less error prone if adding more strings
-
add pseudo interface for language state. MAX_SAGES_ON_BOTTOM must always
change in lockstep with g_lang. this isn't foolproof but better
---------
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>
SGP did not seem to make any use of compilationFlags or debugFlags when
translating from msbuild to cmake, but there could be a thrice removed
transitive include I've missed.
there's a small probability this fixes some obscure UB or one-definition rule
violation that's causing the mystery crashes people have reported
* Add compilationFlags to {exe}
sgp.cpp is not recognizing JA2EDITOR preprocessor definition otherwise and therefore does not read EDITOR_SCREEN_RESOLUTION when starting map editor
* Add debugFlags too
the Ja2.rc file needs to be in the add_executable target for the icon
to appear, and that one requires WinMain.
so get rid of dummy.cpp and put sgp/sgp.cpp in there
Language is now just built once per app (still some JA2UB conditionals
going on in there) but building everything should now take eight times
less work
gather all ENGLISH|GERMAN|CHINESE etc preprocessor hell into a single
library, so to restrict the number of targets that need to be built 8x
this still has UB/EDITOR definitions so that still needs to be dealt
with before we can build it only 8 times
* Move main executable files to their own directory
* Adapt the build to the new file structure
... and fix some weird #include's that were relying on the project root
being an include directory.
- MSBuild has safe exception handlers (safeseh) enabled by default, which
some of our libraries don't support
- also needs legacy_stdio_definitions.lib to be linked
* Use a modifiable user-preset sample for VS 2022/2019
Customizing a repo-tracked preset file doesn't work:
Type in your gamedir for debugging, or toggle verbose mode for the build, or configure Chinese
UB MapEditor: you now have an unstaged `CMakePresets.json` change in your working directory.
very annoying.
Also, Visual Studio 2022's preset support has a bug: if you have a `CMakePresets.json` file,
no matter in which file (user or repo) the preset you have selected is defined, if you click
"Manage Configurations..." it will always open `CMakePresets.json` for editing, setting the
user up for failure and editing the commited-to-repository file.
Having just the `CMakeUserPresets.json` file also sidesteps another poor Visual Studio 2022
decision: hiding in Folder View files that are .gitignore'd (like `CMakeUserPresets.json`).
In the absence of a `CMakePresets.json` file, selecting "Manage Configurations..." will open
the right file for editing.
The workflow is then:
Copy `CMakeUserPresets.json.sample` into `CMakeUserPresets.json` _once_, then customize
that to your heart's content without git bothering you and accidentally adding an
unwanted change to a patch. Or make your own.
* Added auto-copy of profile template.
* declutter things a bit
move function out of root cmakelists.txt file
move user preset template to a presets directory
this is horrible and I hate it
Co-authored-by: CptMoore <39010654+CptMoore@users.noreply.github.com>
* simplify the language/executable validation function
removing the 'ALL' corner-case so that the default behavior is to configure all valid languages and applications allows to simplify this function quite a bit
* keep the CMakePreset.json options listed for ease of use
Tried to stay as close as possible to ja2_2019.sln
On Visual Studio 2022 just Project -> CMake Settings for Ja2, add
the x86 configurations you want and press F7.
Below shows how the -DLanguages -DApplications switches work, If you don't
set them, the CMakeCache.txt of them will be set to ENGLISH and JA2,
respectively:
cmake [...] // nothing set, configure just JA2_ENGLISH.exe by default
cmake [...] -DApplications="JA2UB" // configures just Unfinished Business
cmake [...] build -DApplications="JA2UB;JA2UBMAPEDITOR" // Unfinished Business and UB Map Editor
cmake [...] build -DApplications="JA2UB;JA2MAPEDITOR;ALL" // ALL is in the list, configures every application
cmake [...] build -DApplications="JA2MAPEDITOR;DeathStranding" // fatal error: DeathStranding not an application
cmake [...] -DLanguages="GERMAN" // configures just German targets
cmake [...] build -DLanguages="GERMAN;ENGLISH" // German and English
cmake [...] build -DLanguages="GERMAN;ENGLISH;ALL" // ALL is in the list, configures every language
cmake [...] build -DLanguages="ENGLISH;ESPERANTO" // fatal error: ESPERANTO not supported
