While Nintendo's own documents claim GameCube and Wii disc file symbol tables only support 7-bit ASCII, this is far from the truth. Indeed, even some first-party Nintendo games shipped with Shift-JIS encoded file symbol tables. My guess? The locale of whatever Windows machine mastered a GameCube or Wii disc influenced how wide character strings (UCS-2) were converted to narrow character strings. To account for all possibilites, this update adds extensible multi-byte character set options to NOD-Tool.
A rundown of notable changes:
- "-c XXXXX" option added to set the encoding of the GameCube / Wii ISO(s) being processed.
- "SystemStringConv" renamed to "DiscLocToSystemConv"
- "SystemUTF8Conv" renamed to "SystemToDiscLocConv"
- Help message updated with new info.
- Bugfix: AddBuildName had a logic error wherein the length of the SystemString was being used instead of length of the disc locale string. This would corrupt the File Symbol Table if the disc locale string's length was greater than the SystemString's length.
- Bugfix: recursiveMergeFST was not keeping track of parent indexes at all, meaning nested folders and their contents would be corrupted. I simply copied the way recursiveBuildFST did things to fix this.
- Bugfix (Windows): On Windows, for some reason, Sstat was a typedef for _stat (32-bit) instead of _stat64 (64-bit). This is confounding, because untrimmed Wii ISOs will always be larger than the unsigned 32-bit integer limit (4,699,979,776 bytes vs 4,294,967,295 bytes), meaning the MergeWii errand has never worked for untrimmed ISOs on Windows. Was this never tested??
- Bugfix (Windows): Did you know Windows Command Prompt fully supports Unicode? Stdio streams are now in _O_U16TEXT mode for Windows only. Previously, attempting to print any character that could not be narrowed to your locale's encoding would either silently fail (std functions), or throw an exception (fmt functions). As a minor drawback, narrow character print functions can no longer be used when stdio is in _O_U16TEXT mode, necessitating my PR for Logvisor here: (AxioDL/logvisor#7)
- ExtractionContext::progressCB now uses SystemStringView because widechar printing works correctly on Windows now.
- progFunc lambda no longer throws exceptions when printing unicode because widechar printing works correctly on Windows now.
- Top-level constructors and functions with a Codepage_t parameter have also signatures that default to the US-ASCII codepage.
- DiscGCN constructor
- DiscBuilderGCN constructor
- DiscBuilderGCN::CalculateTotalSizeRequired
- DiscMergerGCN constructor
- DiscMergerGCN::CalculateTotalSizeRequired
- DiscWii constructor
- DiscBuilderWii constructor
- DiscBuilderWii::CalculateTotalSizeRequired
- DiscMergerWii constructor
- DiscMergerWii::CalculateTotalSizeRequired
- OpenDiscFromImage
- Conversion between system encoding and disc locale encoding has checks in place to warn the user if string conversion goes awry.
std::function isn't a trivial type (it's allowed to heap allocate to
store any necessary captures), so we can move it in the constructor to
avoid any unnecessary allocations
std::string_view instances aren't required to be null terminated. Given
this, we can make the functions a little safer by performing an explicit
bounded comparison on the range of characters, making the code more
generic with regards to handling the underlying string data.
Luke Street
Phillip Stephens
Minty-Meeo
Jack Andersen
Lioncash
Henrique Gemignani Passos Lima
cylgom