It's quite possible that FAT mounting succeeds, but on a different device such as a memory card or USB
However, trying to call mkdir/open would then crash as mkdir/open will behave improperly if you call them with a path that specified device which isn't found - and previously ClassiCube always hardcoded for the 'sd' device
1) Fixed can't really control camera (it resets position when you release touch)
2) Fix 'mouse' position being wrong for initial frame after touch begins
3) Fix 'mouse' position using coordinates of bottom screen instead of top screen
3DS: Now also supports using circle pad for moving camera
Wii/PSP/GameCube: Falls back to using default.png from texture pack for fonts in launcher, instead of never displaying any text at all
Fix not being able to create/open files/directories on a real 3DS
Try to fix clicking Home button not doing anything
Fix not returning the right error code when socket creation fails due to being unable to resolve hostname
TCC was generating the problematic instruction sequence:
MOVD XMM0, dword ptr [zero_zero_eight]
MOVD XMM2, dword ptr [RAX]=>velocityY
ADDSS XMM2, XMM0
MOVD XMM0, dword ptr [RBP + stored_t_arg]
MOVAPS XMM2, XMM0
or in pseudocode:
XMM0 = 0.08f
XMM2 = velocityY
XMM2 = XMM2 + XMM0
XMM0 = t
XMM2 = XMM0
at which, it can be seen what the codegen bug is - XMM2 (which holds the value of e->Velocity.Y + 0.08) is overwritten with the value of 't' in preparation for calling Math_Lerp, but the prior value in XMM2 is not stored to another register like XMM1 first
This usually happens when a platform's system fonts completely changed. One common case where this happened was updating Android operating system version on some devices
Fix PSP build not compiling, and makefile not working due to not having -I and -L paths
Fix GameCube build not compiling
Change Haiku build to avoid using libexecinfo
Add github action workflows for 3DS, PSP, GameCube/Wii, Haiku
Based on the CPU registers provided in the crash log, the crash was happening near the end of copying from 'ctx' to 'copy' local variable
Given that the user was running on Windows 95/98, it's quite possible that the 'ctx' CONTEXT was smaller in older operating systems - and so trying to copy a full sized CONTEXT into 'copy' would mean that memory past the smaller sized CONTEXT was wrongly read, which could thus rarely cause an access violation
I can't confirm whether this is actually the case or not though, since I couldn't easily find SDK headers for Windows 95/98.
But since we don't care about StackWalk modifying the CONTEXT provided as an argument anyways (given that the process will be terminated right after this), the simplest solution is to just pass the original 'ctx' to StackWalk instead of passing a copy of the CONTEXT
