Heap is out of the question, as it might be corrupted.
Allocating this much on stack is silly.
So instead, allocate virtual pages to write the information in.
As mentioned in the comment, we only did it ourselves as we once
were compatible with versions before 10.5. But that time has long
gone. So let's update the code to a bit more modern approach.
Only Windows implemented this, and it opens the files to read them
to get a CRC. Doing this in a crash-handler is strange at best.
Lastly, nobody has actually ever used this information to come to
some sort of conclusion. The module-list is used in combination
with the crash.dmp, but this information is already embedded in
there.
It only contains pointers, which nobody can decipher anyway.
So instead, just report "Not supported", like other targets do
when they can't print a sane stack trace.
Basically, we haven't been a good neighbour. Turns out you shouldn't
actually call FcFini when you are done, as some library might still
want to use FontConfig. And they use a shared instance for their
administration.
The idea is that you call FcInit once, and use FcConfigReference
after that to get an instance, you can release. This entry is
ref-counted, and things happen automatically based on that.
At least, I think.
It turns out, for Windows and Linux having the exact memory allows
for easy tracing of an individual. That is exactly against the idea
of the survey. And honestly, we don't need this precision.
That it works for the version we have packaged it pure coincidence, as that is
one of the few versions that due to a bug allow it. So add the appropriate
template specialisations to support it out-of-the-box within OpenTTD.
On first start-up, the game will ask if you want to participate
in our automated survey. You have to opt-in, and can easily opt-out
(via the Options) at any time.
When opt-in, whenever you exit a game, a JSON blob will be send
to the survey server hosted by OpenTTD. This JSON blob contains
information that gives a global picture of the game just played:
- What settings were used
- How many humans vs AIs
- How long the game has been played
- Basic information about the OS / CPU
All this information is kept very generic, so there is no
chance we send private information to our survey server.
Nothing in the JSON blob could identify you as a person; it
mostly tells about the game played. At any time you can see
what the JSON blob includes, by pressing the "Preview Survey
Results" button in-game.
This to prevent compilation issues between runs with and without precompiled
headers. Also remove the headers from the rest of the code base as they are
not needed there anymore, although they do relatively little harm.
