Saving a tspack should now also work correctly on wine.
There was another std::chrono issue (replaced by win32 calls) and moved towards std::filestream to save the tspack since the COM use with IShellItem_BindToHandler did not work as expected too (returns REGDB_E_CLASSNOTREG).

Tested OK on Windows.

Linux test failing for now on stock Steam Deck + XLCore config. Current state is an apparent bug in Wine >= 8.5 that causes a crash reading PDBs leading to no VEH screen and the game instead hanging indefinitely. Tested OK with Wine 7.10.r3.

Crash screen on Steam Deck takes about 30 seconds to pop, though this is likely environmental. Works fine in Gamescope, we have plenty of room to add a "generate tspack" button should we want it, though it does clip if anyone makes the mistake of opening the stacktrace log screen. Restart tested OK. Crash files are generated in logs/ folder, they otherwise seem fine.

Yeah the pdb issue on Wine >= 8.5 is a bit annoying and not something I initially tested for.
In the meantime the last commit should fix it (as in properly run into the next crash handler), until we update our wine to fix that and then it should automagically start working.
As a side bonus, if for whatever reason the crash handler dies on windows as well, the game will no longer hang and continue with the next crash handler similarly.

Windows tested OK.

Wine 7.10 tests OK, VEH pops up.

Stock wine does not pop VEH (as expected); Wine's own exception handler pops instead. (Is this intended?)

Wine's own exception handler pops instead.

This should greatly help debugging native crashes (plus the managed stack, if useful, will also be logged)

Also of note: on Windows, forcefully killing DalamudCrashHandler.exe after the game crashes will now cause FFXIV to quit after a few seconds. Prior behavior was to hang indefinitely. Windows will also generate a dump file for us at %LOCALAPPDATA%\CrashDumps in this case.

I think this is fine, so +1ing.