fix: activate on Windows machines with a non-ASCII computer name - #37
Merged
Merged
Conversation
read_host_name() used GetComputerNameExA, which answers in the ANSI code page, so a computer name like Björn-PC reached nlohmann::json as bytes that are not UTF-8 and dump() threw type_error.316, failing both online and offline activation. Read it with GetComputerNameExW and transcode to UTF-8 instead, in the default resolver and for the legacy resolver's device name. No device id changes: the opt-in host-name fallback and the legacy id still hash the ANSI reading. The device name is only a label, so bytes in it that are not UTF-8 now become U+FFFD rather than failing the request. A device id that is not UTF-8 is refused before anything is sent, since a repaired id would bind a license that cannot validate on the device. The JUCE controller called every exception that was not a Moonbase error a connection problem, which sends users and developers looking at the network. Both bundled transports report a failed connection as api_error, so anything else is now shown in its own words, and a machine file that cannot be generated no longer claims the write failed. Exception text is decoded as UTF-8 rather than through juce::String's ASCII constructor, and http_transport::send documents the api_error contract.
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
github-actions Bot
pushed a commit
that referenced
this pull request
Oct 5, 2026
## [4.7.1](v4.7.0...v4.7.1) (2026-10-05) ### Bug Fixes * activate on Windows machines with a non-ASCII computer name ([#37](#37)) ([87816c4](87816c4))
|
🎉 This PR is included in version 4.7.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Windows the device name was read with GetComputerNameExA, so any non-ASCII computer name reached nlohmann::json as ANSI bytes and dump() threw type_error.316, failing online and offline activation; it is now read with GetComputerNameExW and transcoded to UTF-8 (also for the legacy resolver's name), with no device id changes since the host-name fallback and legacy id still hash the ANSI reading. A device name that is not UTF-8 now gets U+FFFD instead of failing the request, while a device id that is not UTF-8 is refused before anything is sent, because a repaired id would bind a license that cannot validate on the device. The JUCE controller no longer calls every non-Moonbase exception a connection problem: anything other than a transport's api_error is shown in its own words, a machine file that fails to generate says why, and exception text is decoded as UTF-8. http_transport::send now documents that a failed connection must be reported as api_error with status 0, and the docs describe the new error copy.