Turns out there was unused code that dealt with strings
that may or may not have been initialized, and treated
them as multi-byte strings even though they were unicode
strings.
I don't actually understand why this would cause a failure
only on Windows Server 2012, but this change definitely fixed
the problem, and the code removed was unnecessary and wrong anyways.
While at it, improved error reporting in case we fail to
get the link to the bootstrap tarball, or download it.
Also fixed a bug that broke login/signup (due to passing a
char* instead of a wchar_t*)
Uses the https://packages.meteor.com/bootstrap-link
URL to generate a link to the windows bootstrap tarball.
With this change we no longer have to build a new installer
for every release.
This API actually lets us download the bootstrap tarball from cloudfront
on Windows Server, /and/ correctly reads the proxy settings from Internet
Explorer.
This is a step on the way to building an installer that always
fetches the latest release of Meteor, so that we don't need to
build a new installer for every release.
TODO:
* Expose a new endpoint on https://package.meteor.com with the latest
release, and consume it in the installer
* Use libcurl to fetch the installer, so that we can bypass the TLS
settings on Windows Server which by default don't let you fetch
HTTPS assets that use TLS 1.2 (as do ours)
* Automatically detect and use the proxy settings configured in
Internet Explorer, eg
http://stackoverflow.com/questions/202547/how-do-i-find-out-the-browsers-proxy-settings
Older installers, like the one on http://win.meteor.com
populated the same directory as our new installer, but with
different files. Specifically, meteor.exe which runs before
our meteor.bat. So we delete the contents of the installed
directory before starting the install.
