macOS moves "dangerous" applications into a read-only [/private]
filesystem. This messes up with the updater and default P2Pool and
XMRig paths.
If [/private] is detected, show a panic screen upon Gupax startup
telling the user to move it to [/Applications]. This _seems_ to
make macOS relax a little (after an arbitrary amount of time...)
Bare metal windows was complaining about this DLL, so it is now
included statically using [https://docs.rs/static_vcruntime/].
I tried statically linking everything for Windows but:
1. It's not necessary, pretty much all DLLs needed
(except this one) are included in Windows 7+ by default
2. It's a pain in the ass to build everything
statically, especially since Gupax needs OpenSSL.
(building OpenSSL on Windows == hell)
Windows/macOS were having console artifacts, escape codes and
random newlines would show up in P2Pool/XMRig output. After
thinking about it for a while, I realized I left the PTY
size to the default [24 rows/80 columns], hence the PTYs
prematurely inserting newlines and weird escape codes.
It works fine after setting it to [100/1000]. Interestingly,
Linux worked completely fine on 24/80, probably resizes internally.
Cargo: Cleanup unused dependencies, enable some build optimizations
Tor: Arti doesn't seem to work on macOS
Even a bare Arti+Hyper request doesn't seem to work, so it's
probably not something to do with Gupax. A lot of issues only
seem to popup in a VM (OpenGL, TLS) even though on bare metal
Gupax runs fine, so Tor might work fine on real macOS but I don't
have real macOS to test it. VM macOS can't create a circuit, so,
disable by default and add a warning that it's unstable.
P2Pool: Let selected_index start at 0, and only +1 when printing
to the user, this makes the overflow math when adding/deleting a
lot more simple because selected_index will match the actual index
of the node vector
[og: State] is now completely wrapped in an [Arc<Mutex>] so that
when the update is done, it can [.lock()] the CURRENT runtime
settings of the user and save to [gupax.toml] instead of using an
old copy that was given to it at the beginning of the thread.
In practice, this means users can change settings around during
an update and the update finishing and saving to disk won't be
using their old settings, but the current ones. Wrapping all of
[og: State] within in [Arc<Mutex>] might be overkill compared to
message channels but [State] really is just a few [bool]'s, [u*],
and small [String]'s, so it's not much data.
To bypass a deadlock when comparing [og == state] every frame,
[og]'s struct fields get cloned every frame into separate
variables, then it gets compared. This is also pretty stupid, but
again, the data being cloned is so tiny that it doesn't seem to
slow anything down.
