nod/driver/main.cpp

320 lines
8.6 KiB
C++
Raw Normal View History

The Encoding Update 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.
2021-06-27 01:26:20 -07:00
#include <array>
#include <cstddef>
#include <cstdint>
2017-12-28 23:57:54 -08:00
#include <cstdio>
#include <cstring>
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
#if _WIN32
#include <fcntl.h>
#include <io.h>
#endif
#include <logvisor/logvisor.hpp>
#include <nod/DiscBase.hpp>
#include <nod/DiscGCN.hpp>
#include <nod/DiscWii.hpp>
#include <nod/nod.hpp>
2015-06-29 23:46:19 -07:00
2018-12-07 21:21:47 -08:00
static void printHelp() {
fmt::print(stderr, FMT_STRING(
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
"Usage:\n"
" nodtool extract [options] <image-in> [<dir-out>]\n"
" nodtool makegcn [options] <fsroot-in> [<image-out>]\n"
" nodtool makewii [options] <fsroot-in> [<image-out>]\n"
" nodtool mergegcn [options] <fsroot-in> <image-in> [<image-out>]\n"
" nodtool mergewii [options] <fsroot-in> <image-in> [<image-out>]\n"
"Options:\n"
" -f Force (extract only)\n"
" -v Verbose details (extract only).\n"));
}
#if _MSC_VER
#include <nowide/args.hpp>
2016-01-20 22:30:37 -08:00
#define PRISize "Iu"
int main(int argc, char* argv[]) {
nowide::args _(argc, argv);
2015-07-02 13:37:07 -07:00
#else
2016-01-20 22:30:37 -08:00
#define PRISize "zu"
int main(int argc, char* argv[]) {
2015-07-02 13:37:07 -07:00
#endif
2018-12-07 21:21:47 -08:00
/* Enable logging to console */
logvisor::RegisterStandardExceptions();
logvisor::RegisterConsoleLogger();
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
int argidx = 1;
std::string errand;
2018-12-07 21:21:47 -08:00
bool verbose = false;
nod::ExtractionContext ctx = {true, [&](std::string_view str, float c) {
2018-12-07 21:21:47 -08:00
if (verbose)
fmt::print(stderr, FMT_STRING("Current node: {}, Extraction {:g}% Complete\n"),
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
str, c * 100.f);
2018-12-07 21:21:47 -08:00
}};
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
while (argidx < argc) {
if (!nod::StrCaseCmp(argv[argidx], "-f")) {
2018-12-07 21:21:47 -08:00
ctx.force = true;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
++argidx;
continue;
} else if (!nod::StrCaseCmp(argv[argidx], "-v")) {
2018-12-07 21:21:47 -08:00
verbose = true;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
++argidx;
continue;
} else if (errand.empty()) {
errand = argv[argidx];
++argidx;
continue;
} else {
break;
}
}
2018-12-07 21:21:47 -08:00
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
if (errand.empty()) {
printHelp();
return 1;
2018-12-07 21:21:47 -08:00
}
2015-09-27 18:55:59 -07:00
auto progFunc = [&](float prog, std::string_view name, size_t bytes) {
fmt::print(FMT_STRING("\r "));
if (bytes != SIZE_MAX)
fmt::print(FMT_STRING("\r{:g}% {} {} B"), prog * 100.f, name, bytes);
2018-12-07 21:21:47 -08:00
else
fmt::print(FMT_STRING("\r{:g}% {}"), prog * 100.f, name);
2018-12-07 21:21:47 -08:00
fflush(stdout);
};
if (errand == "extract") {
std::string imageIn;
std::string dirOut;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
while (argidx < argc) {
if (imageIn.empty()) {
imageIn = argv[argidx];
++argidx;
continue;
} else if (dirOut.empty()) {
dirOut = argv[argidx];
++argidx;
continue;
} else {
printHelp();
return 1;
}
}
if (dirOut.empty())
dirOut = ".";
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
2018-12-07 21:21:47 -08:00
bool isWii;
std::unique_ptr<nod::DiscBase> disc = nod::OpenDiscFromImage(imageIn, isWii);
2018-12-07 21:21:47 -08:00
if (!disc)
return 1;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
nod::Mkdir(dirOut.c_str(), 0755);
2018-12-07 21:21:47 -08:00
nod::IPartition* dataPart = disc->getDataPartition();
if (!dataPart)
return 1;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
if (!dataPart->extractToDirectory(dirOut, ctx))
2018-12-07 21:21:47 -08:00
return 1;
} else if (errand == "makegcn") {
std::string fsrootIn;
std::string imageOut;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
while (argidx < argc) {
if (fsrootIn.empty()) {
fsrootIn = argv[argidx];
++argidx;
continue;
} else if (imageOut.empty()) {
imageOut = argv[argidx];
++argidx;
continue;
} else {
printHelp();
return 1;
}
}
if (imageOut.empty())
imageOut = fsrootIn + ".gcm";
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
2018-12-07 21:21:47 -08:00
/* Pre-validate path */
nod::Sstat theStat;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
if (nod::Stat(fsrootIn.c_str(), &theStat) || !S_ISDIR(theStat.st_mode)) {
nod::LogModule.report(logvisor::Error, FMT_STRING("unable to stat {} as directory"), fsrootIn);
2018-12-07 21:21:47 -08:00
return 1;
}
2015-06-29 23:46:19 -07:00
if (!nod::DiscBuilderGCN::CalculateTotalSizeRequired(fsrootIn))
2018-12-07 21:21:47 -08:00
return 1;
2018-12-07 21:21:47 -08:00
nod::EBuildResult ret;
nod::DiscBuilderGCN b(imageOut, progFunc);
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
ret = b.buildFromDirectory(fsrootIn);
2016-01-20 22:30:37 -08:00
fmt::print(FMT_STRING("\n"));
2018-12-07 21:21:47 -08:00
if (ret != nod::EBuildResult::Success)
return 1;
} else if (errand == "makewii") {
std::string fsrootIn;
std::string imageOut;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
while (argidx < argc) {
if (fsrootIn.empty()) {
fsrootIn = argv[argidx];
++argidx;
continue;
} else if (imageOut.empty()) {
imageOut = argv[argidx];
++argidx;
continue;
} else {
printHelp();
return 1;
}
}
if (imageOut.empty())
imageOut = fsrootIn + ".iso";
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
2018-12-07 21:21:47 -08:00
/* Pre-validate path */
nod::Sstat theStat;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
if (nod::Stat(fsrootIn.c_str(), &theStat) || !S_ISDIR(theStat.st_mode)) {
nod::LogModule.report(logvisor::Error, FMT_STRING("unable to stat {} as directory"), fsrootIn);
2018-12-07 21:21:47 -08:00
return 1;
}
2018-12-07 21:21:47 -08:00
bool dual = false;
if (!nod::DiscBuilderWii::CalculateTotalSizeRequired(fsrootIn, dual))
2018-12-07 21:21:47 -08:00
return 1;
2016-01-22 15:45:58 -08:00
2018-12-07 21:21:47 -08:00
nod::EBuildResult ret;
nod::DiscBuilderWii b(imageOut, dual, progFunc);
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
ret = b.buildFromDirectory(fsrootIn);
fmt::print(FMT_STRING("\n"));
2018-12-07 21:21:47 -08:00
if (ret != nod::EBuildResult::Success)
return 1;
} else if (errand == "mergegcn") {
std::string fsrootIn;
std::string imageIn;
std::string imageOut;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
while (argidx < argc) {
if (fsrootIn.empty()) {
fsrootIn = argv[argidx];
++argidx;
continue;
} else if (imageIn.empty()) {
imageIn = argv[argidx];
++argidx;
continue;
} else if (imageOut.empty()) {
imageOut = argv[argidx];
++argidx;
continue;
} else {
printHelp();
return 1;
}
}
if (imageOut.empty())
imageOut = fsrootIn + ".gcm";
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
2018-12-07 21:21:47 -08:00
/* Pre-validate paths */
nod::Sstat theStat;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
if (nod::Stat(fsrootIn.c_str(), &theStat) || !S_ISDIR(theStat.st_mode)) {
nod::LogModule.report(logvisor::Error, FMT_STRING("unable to stat {} as directory"), fsrootIn);
2018-12-07 21:21:47 -08:00
return 1;
}
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
if (nod::Stat(imageIn.c_str(), &theStat) || !S_ISREG(theStat.st_mode)) {
nod::LogModule.report(logvisor::Error, FMT_STRING("unable to stat {} as file"), imageIn);
2018-12-07 21:21:47 -08:00
return 1;
}
2018-12-07 21:21:47 -08:00
bool isWii;
std::unique_ptr<nod::DiscBase> disc = nod::OpenDiscFromImage(imageIn, isWii);
2018-12-07 21:21:47 -08:00
if (!disc) {
nod::LogModule.report(logvisor::Error, FMT_STRING("unable to open image {}"), imageIn);
2018-12-07 21:21:47 -08:00
return 1;
}
if (isWii) {
nod::LogModule.report(logvisor::Error, FMT_STRING("Wii images should be merged with 'mergewii'"));
2018-12-07 21:21:47 -08:00
return 1;
}
if (!nod::DiscMergerGCN::CalculateTotalSizeRequired(static_cast<nod::DiscGCN&>(*disc), fsrootIn))
2018-12-07 21:21:47 -08:00
return 1;
2018-12-07 21:21:47 -08:00
nod::EBuildResult ret;
nod::DiscMergerGCN b(imageOut, static_cast<nod::DiscGCN&>(*disc), progFunc);
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
ret = b.mergeFromDirectory(fsrootIn);
fmt::print(FMT_STRING("\n"));
2018-12-07 21:21:47 -08:00
if (ret != nod::EBuildResult::Success)
return 1;
} else if (errand == "mergewii") {
std::string fsrootIn;
std::string imageIn;
std::string imageOut;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
while (argidx < argc) {
if (fsrootIn.empty()) {
fsrootIn = argv[argidx];
++argidx;
continue;
} else if (imageIn.empty()) {
imageIn = argv[argidx];
++argidx;
continue;
} else if (imageOut.empty()) {
imageOut = argv[argidx];
++argidx;
continue;
} else {
printHelp();
return 1;
}
}
if (imageOut.empty())
imageOut = fsrootIn + ".iso";
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
2018-12-07 21:21:47 -08:00
/* Pre-validate paths */
nod::Sstat theStat;
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
if (nod::Stat(fsrootIn.c_str(), &theStat) || !S_ISDIR(theStat.st_mode)) {
nod::LogModule.report(logvisor::Error, FMT_STRING("unable to stat {} as directory"), fsrootIn);
2018-12-07 21:21:47 -08:00
return 1;
}
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
if (nod::Stat(imageIn.c_str(), &theStat) || !S_ISREG(theStat.st_mode)) {
nod::LogModule.report(logvisor::Error, FMT_STRING("unable to stat {} as file"), imageIn);
2018-12-07 21:21:47 -08:00
return 1;
}
2018-12-07 21:21:47 -08:00
bool isWii;
std::unique_ptr<nod::DiscBase> disc = nod::OpenDiscFromImage(imageIn, isWii);
2018-12-07 21:21:47 -08:00
if (!disc) {
nod::LogModule.report(logvisor::Error, FMT_STRING("unable to open image {}"), argv[3]);
2018-12-07 21:21:47 -08:00
return 1;
}
if (!isWii) {
nod::LogModule.report(logvisor::Error, FMT_STRING("GameCube images should be merged with 'mergegcn'"));
2018-12-07 21:21:47 -08:00
return 1;
}
2018-12-07 21:21:47 -08:00
bool dual = false;
if (!nod::DiscMergerWii::CalculateTotalSizeRequired(static_cast<nod::DiscWii&>(*disc), fsrootIn, dual))
2018-12-07 21:21:47 -08:00
return 1;
2018-12-07 21:21:47 -08:00
nod::EBuildResult ret;
nod::DiscMergerWii b(imageOut, static_cast<nod::DiscWii&>(*disc), dual, progFunc);
The Encoding Update 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.
2021-06-27 01:26:20 -07:00
ret = b.mergeFromDirectory(fsrootIn);
2015-06-29 23:46:19 -07:00
fmt::print(FMT_STRING("\n"));
2018-12-07 21:21:47 -08:00
if (ret != nod::EBuildResult::Success)
return 1;
} else {
printHelp();
return 1;
}
nod::LogModule.report(logvisor::Info, FMT_STRING("Success!"));
2018-12-07 21:21:47 -08:00
return 0;
}