iNavFlight
Handling of SITL binaries
Currently, the SITL binaries are delivered for all architectures and a decision is made at runtime which one will be executed. However, we do not have any logic to filter by architecture, only by OS:
https://github.com/iNavFlight/inav-configurator/blob/5422e56423df02b3ff726857dd59453881945099/js/sitl.js#L140-L156
This is not a problem under MacOS, as the Mac binaries are universal for Intel/Arm64, but it is a problem under Linux (x64/ARM) and we do not have Windows 32-bit SITL. Is Windows 32-bit still relevant at all? Should we keep it?
It would make more sense to only deliver the SITL for the corresponding OS and architecture. In addition, the SITLs are fixed in the repo, so the nightlys always have an outdated SITL until someone updates them manually.
Suggestion: Do not include the SITL binaries in the repository. Option 1: Add the appropriate SITL binary in the CI action. Disadvantage: If someone builds the configurator locally, the SITL still has to be added manually. Option 2: Integrate the SITL binaries via submodule and add a step in electron forge to include only the appropriate SITL. To do this, the SITL binaries must not only be created as zip assets in the release in the INAV nightly repository, but a commit must always be created and stored directly in the repository. Option 3: Ship out the Configurator without SITL binaries and add a option to download the binary on demand.
Is Windows 32-bit still relevant at all? Should we keep it?
There are no 32-bit builds of Windows still supported by Microsoft (getting security updates). Simply viewing a malicious jpeg picture will get a 32-bit Windows machine compromised by malware. With an aim to improve things for the future, we can probably figure Win32 is on the way out of not already dead. I wouldn't worry too much about a SITL for it.
There is no ia-32 cygwin, nor has there been for a while. Building a win32 cygwin is not practical.
