Separate downloader process

[nmlgc]

I've been wanting to do this for a long time, and half of fast bootstrapping would require it as well. This is how it could work:

• When thcrap_loader.exe is started, it checks whether thcrap_downloader.exe exists and launches it if it does. Otherwise, it goes straight to launching the patched game, as it does currently. This will continue to allow people to opt out of updates.
• thcrap_downloader then determines whether there are any updates and how much to download in a blocking manner before starting the game itself.
• Once the game is started, the downloader process remains open in the background to fetch new updates while the game is runnning.
• It also remains open after the game was closed, in order to inform users about the updates that happened in the background.

The updater needs to block in the following cases:

• Technical patch changes that can't easily be repatched while the game is running, such as binary hacks and breakpoints.
• Any changes to the dependencies of selected patches, as this might potentially require user interaction (see below).
• The initial bootstrapping process of a patch. (It may be better, though, to instead define some sort of threshold value above which a patch update becomes generally blocking. This would also help to accommodate scenarios where users quit the initial blocking download after a few files, then later restart and wonder/complain why next to nothing is patched because the downloader is still running in the background...)

Reasons for putting the downloader into a separate process, rather than just keeping it in a thread within the game process:

• Stability. In rare cases, the download thread seems to cause a crash before the title screen, and it also tends to crash if the user immediately quits on the resolution dialog while an update is in progress.
• Antivirus software would be less likely to target thcrap. I looked into the situation with Norton, and it only killed the game process on the HTTP GET requests made by the uploader.
• Users would not have to add firewall exceptions for every single game executable, but only once for the downloader.

Reasons why this absolutely must have a GUI:

• Progress bars are obviously prettier.

• The Windows console subsystem still can't render Unicode properly – or at least not without requiring extensive configuration together with correct fonts, which I personally have never got working.

• We could add a nice display of the differences between the newly downloaded content and the existing files, so that users can easily see what changed in the current update. (I can already imagine that people would then be calling for some sort of spoiler protection, though?)

• We could add a "Start game now" button that is enabled once the downloader has finished all blocking parts of an update, as an alternative to just immediately running the game in that case.

• User interaction will be necessary to manage digital signatures on patches, once we have them.

• We could also give users a choice between available alternative patches that offer the same features. This would implement our new focus on namespacing, and is especially important for changes to the underlying dependencies after configuration time. (Really, it's about time that our design acknowledged the fact that maintainers of anything Touhou are most likely not going to stay around forever.)

  As you know, dependencies are stated using the syntax

  [repository/]id
  

  It is already possible to omit the repository part. Currently, this results in the patch being randomly picked from a repository that offers a patch with the same ID. With user interaction, we could instead ask the user which patch to choose.

  This question should come with a detailed overview of both patches, (rendering each patch's readme.md next to each other would do). This allows users to make a somewhat informed decision between two patches implementing the same functionality, even if they haven't followed the development of the patches in question (which they most likely haven't).

Things to consider

• Looking at Steam, it seems that gamers have largely accepted updates delaying game startups from time to time. If that's the case, we could just block on every update to simplify the design and the implementation.
• How much overlap will there be with the future configuration tool? If the answer is "a lot", why don't merge them outright?