Fixes random .NET plugin crash caused by the console window being freed
on the same process.
### Problem description
Sometimes when launching from the explorer ImHex crashes
### Implementation description
We've implemented a launcher to avoid freeing the std streams, that
generated the bug.
### Screenshots
N/A
### Additional things
Blame windows console subsystem
As requested on Discord, a PR to revert the FPS limiter back to the one
that was used in v1.30.1.
The new FPS limiter seems to be flawed in that it runs at about half the
speed it is supposed to be.
See this illustration:
Left is v1.30.1, right is the new version (without this fix). See how
long it takes to respectively reach 0xE90.
This is not a performance issue, because when you fully unlock the
framerate on the right, it's just as fluent as on the left.
This PR intends to add support for .NET scripts that can extend ImHex's
functionality in a portable and cross-platform way.
---------
Co-authored-by: Justus Garbe <55301990+Nowilltolife@users.noreply.github.com>
This PR it just a hack to fix#1160 , it doesn't solve the underlying
problem.
It fixes the problem because by using execvp() directly, it avoids the
call to `sh` done with `system()`, which has a bug on Ubuntu 22.04 which
makes it i,compatibles with the glibc inside the AppImage.
It doesn't fix the underlying problem because the programs we call
themselves still link to the AppImage's libraries instead of the system
ones.
This PR fixes some things about crash handling:
- when the terminate handler is called, immediately set it back to the
original one, so can't make a recursion if the crash-handling code fails
- Only save projects if the crash occured after Imhex finished startup
- do not update the project location when saving the crash backup file:
this will remove problems when `EventAbnormalTermination` is called
before `crashCallback()`
I also added a bit more documentation
