I am packaging a game and when I create it with copy it creates a wii iso

I tried adding setup.txt and everything from the extracted disc
I have tried regular iso to be safe
Whats the magic to creating a gamecube disc?

wit VERSION
wit: Wiimms ISO Tool v3.05a r8638 x86_64 - Dirk Clemens - 2022-08-27

wit -vvv copy tmp game.ciso

wit DUMP game.ciso

Real path: /data/game.ciso
Virtual size: 118240000/hex = 4699979776 = 4482 MiB
Scrubbed size: 100000/hex = 1048576 = 1 MiB, 0.02%, 32*32K
CISO file size: 408000/hex = 4227072 = 4128 KiB, 0.09%, 403.1%
File & disc type: CISO/WII & Wii

would be very nice as FAT doesn't support sparse files hence formatting adds extra whole size write.

I just coded a frontend for WIT: https://github.com/mq1/rusty-wit-gui

It's still a WIP, but as of now my program is set to automatically download WIT from https://wit.wiimm.de/ (I stated this in the readme). Can I do that, or should I provide instructions to download WIT manually?

What license is this software intended to use?

https://choosealicense.com/

Currently, the Makefile only supports gcc. Please add clang support.

Edit: please also support clang for wszst

when I do ./install.sh when im in the folder to install. When I click Enter it says: xattr: no such file

this is the dependencies that don't exist:
xattr: No such file: /usr/local/bin/prlexec
xattr: No such file: /usr/local/bin/prl_disk_tool
xattr: No such file: /usr/local/bin/prlcore2dmp
xattr: No such file: /usr/local/bin/prlsrvctl
xattr: No such file: /usr/local/bin/prlctl
xattr: No such file: /usr/local/bin/prl_convert
xattr: No such file: /usr/local/bin/prl_perf_ctl.

However when I go to the folder (the usr folder) they appear as alias and when I click "show original" it says that the original file cannot be found.
OS: MacOS
Version: Sonoma 14.4 Beta
System: M1 2020 Macbook Pro

I tried to build with the following *FLAGS to optimize the build: -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing

Note the -Werror=* flags are used to help detect cases where the compiler tries to optimize by assuming UB cannot exist in the source code -- if it does exist, ordinarily the code would be miscompiled, and this says to make the miscompilation a fatal error.

I got this error:

x86_64-pc-linux-gnu-gcc -march=native -fstack-protector-all -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-clash-protection -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Werror=int-conversion -Werror=incompatible-pointer-types -I./dclib -std=gnu99 -fno-strict-aliasing -Wall -Wno-parentheses -Wno-unused-function -Isrc/libwbfs -Isrc -I./src/ui -I. -Iwork -Wno-format-truncation -march=x86-64 -DHAVE_ZLIB=1 -DHAVE_POSIX_FALLOCATE=1 -DHAVE_FIEMAP=1 -DLARGE_FILES -D_FILE_OFFSET_BITS=64 -DWIT -DDEBUG_ASSERT -DEXTENDED_ERRORS=1 -D_7ZIP_ST=1 -D_LZMA_PROB32=1 -DUSE_SHA_LIB -Wl,-O1 -Wl,--as-needed -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wl,--defsym=__gentoo_check_ldflags__=0 gen-ui.o \
	cert.o dclib-basics.o dclib-cli.o dclib-color.o dclib-debug.o dclib-file.o dclib-numeric.o dclib-option.o dclib-parser.o dclib-regex.o dclib-shift-jis.o dclib-tables.o dclib-ui.o dclib-utf8.o dclib-vector.o dclib-xdump.o file-formats.o iso-interface.o lib-bzip2.o lib-ciso.o lib-dol.o lib-file.o lib-gcz.o lib-lzma.o lib-sf.o lib-std.o lib-wdf.o lib-wia.o libwbfs.o match-pattern.o patch.o rijndael.o sha1_one.o sha1dgst.o src/lzma/LzFind.o src/lzma/Lzma2Dec.o src/lzma/Lzma2Enc.o src/lzma/LzmaDec.o src/lzma/LzmaEnc.o ssl-asm.o titles.o tools.o wbfs-interface.o wiidisc.o  -ltinfo -lz -lm  -lbz2  -lcrypto -o gen-ui
src/dclib-utf8.h:116:25: error: type of ‘DecomposeUnicode’ does not match original declaration [-Werror=lto-type-mismatch]
  116 | const dcUnicodeTripel * DecomposeUnicode ( ulong code );
      |                         ^
./dclib/dclib-utf8.c:2230:25: note: type mismatch in parameter 1
 2230 | const dcUnicodeTripel * DecomposeUnicode ( u32 code )
      |                         ^
./dclib/dclib-utf8.c:2230:25: note: type ‘u32’ should match type ‘ulong’
./dclib/dclib-utf8.c:2230:25: note: ‘DecomposeUnicode’ was previously declared here
src/dclib-utf8.h:101:9: error: type of ‘ScanUTF8AnsiChar’ does not match original declaration [-Werror=lto-type-mismatch]
  101 | ulong   ScanUTF8AnsiChar        ( ccp * str );
      |         ^
./dclib/dclib-utf8.c:686:5: note: return value type mismatch
  686 | u32 ScanUTF8AnsiChar ( ccp * p_str )
      |     ^
./dclib/dclib-utf8.c:686:5: note: type ‘u32’ should match type ‘ulong’
./dclib/dclib-utf8.c:686:5: note: ‘ScanUTF8AnsiChar’ was previously declared here
./dclib/dclib-utf8.c:686:5: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
src/dclib-utf8.h:104:9: error: type of ‘PrintUTF8Char’ does not match original declaration [-Werror=lto-type-mismatch]
  104 | char *  PrintUTF8Char           ( char * buf, ulong code );
      |         ^
./dclib/dclib-utf8.c:987:8: note: type mismatch in parameter 2
  987 | char * PrintUTF8Char ( char * buf, u32 code )
      |        ^
./dclib/dclib-utf8.c:987:8: note: type ‘u32’ should match type ‘ulong’
./dclib/dclib-utf8.c:987:8: note: ‘PrintUTF8Char’ was previously declared here
./dclib/dclib-utf8.c:987:8: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
lto1: some warnings being treated as errors
lto-wrapper: fatal error: x86_64-pc-linux-gnu-gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:409: gen-ui] Error 1

Downstream report: https://bugs.gentoo.org/859319
Full build log: build.log

Currently, as docs say, "Anyway, NKIT images are not supported yet, but detected to print warnings."
Having this support would be awesome!

Hello,
as the bin files were unsigned on Mac version, I tried to compile the project by myself
here's the log
$ make /Users/omerien/Downloads/wiimms-iso-tools-master/project awk: calling undefined function gensub input record number 11, file source line number 1 make: Nothing to be done for /Users/omer/Downloads/wiimms-iso-tools-master/project'.`

I don't know what to do so can you help me please ?

Edit : fixed by using this version : #13

Some games such as Medal of Honor Heroes 2 has the main executable in another DOL (DATA/files/game.dol) whereas the main.dol is only used as a launcher. Having a way to specify another dol would allow to use wit cp with options like --wiimmfi, --http, --domain to patch the game.

hi folk i'm having a problem with this i try to convert iso to wbfs.. i use this command wit copy --bwfs file.iso /dest the process end without error or warning but goto the wii no detected the game then i try with others wbfs games and no problem then the problem is in the convertion and try in ubuntu and mac os same result.. what i'm doing wrong? thank for help

I'm trying to scrub the junk data that bloats the ISO size of my backups. I was under the impression that wit can do this.

1. I downloaded wit-v3.03a-r8245-mac.tar.gz from https://wit.wiimm.de/ and extracted it to /tmp/wit/
   Note: this only works on Catalina. It does not run at all on High Sierra
2. I attempted to scrub a game backup to reduce its size:

   ./bin/wit CP gamecube-backup-xxxx.iso gamecube-backup-xxxx.gcm
   *****  wit: Wiimms ISO Tool v3.03a r8245 mac - Dirk Clemens - 2020-08-03  *****
   * COPY/SCRUB 1/1 ISO:./gamecube-backup-xxxx.iso -> ISO:./gamecube-backup-xxxx.gcm

3. The resulting size was exactly the same, despite that is says it's doing a "SCRUB", but I know that the actual game size is much smaller

Do I need another option? Am I misunderstanding what wit is supposed to do?

When using wit and the patching option of --tt-id 'your choice' with said image .this image checks main.dol against tmd and strings will be incorrect .ie not mach and not boot .. you have to hand edit tmd and main.dol to boot image. I can provide xxd dumps of tmd if needed.. you code Wonderful tools btw ... thanks .

Batch renaming of a collection of ISOs doesn't work very well, since there are some games that span multiple discs and some games that come in multiple versions. I suggest to support new escape sequences to handle these cases.
I understand that both the version and the disc number are not always wanted in the filename, so I propose the following:

• A default string for disc number and version, i.e. " (Disc #)" and " (v1.##)"
• An option to override it, using placeholders, i.e. --discnum-seq ' - Disc number %D -' and --discver-seq ' - Ver. %V -'
• An escape sequence to always insert the disc number (or version) and another to add it only when non-zero (for example %d and %v vs %D and %V)

To explain a little bit better, let's suppose there are the following files in the current directory:

• Game 1.iso
• Game 2 d1.iso
• Game 2 d2.iso
• Game 3 (1.02).iso

The command wit MOVE -r . '%T%V%D.%E' will rename them to

• Game 1 (v1.00) (Disc 1).iso
• Game 2 (v1.00) (Disc 1),iso
• Game 2 (v1.00) (Disc 2).iso
• Game 3 (v1.02) (Disc 1).iso

while wit MOVE --discnum-seq ' ver. %V' --discver-seq ' disc %D' -r . '%T%d%v.%E' will lead to

• Game 1.iso
• Game 2.iso
• Game 2 disc 2.iso
• Game 3 ver. 1.02.iso

Ideally also the first disc of game 2 should have the disc number, but that would mean changing the behaviour of wit to check for other discs every time it finds a "disc 1", since disc 1 of a multi-disc game is indistinguishable from a single-disc game.

By specs the disc number is the 7th byte of the header, while the disc version is the following byte. The disc number starts at 0 for disc 1, while the version is usually indicated as 1.## where ## is the version byte (in decimal). For example a value of 0x01 corresponds to 1.01, while 0x0A to 1.10. I suggest to handle values greater than 99 by changing the first digit (for example 0x6B becomes 2.07).

I don't know if these two values are stored in other formats other than ISO, but I think so.

Thank you for your consideration and for this awesome tool.

$ wit move xxx.wbfs "%I_%T/%I.wbfs"
*****  wit: Wiimms ISO Tool v3.01a r0 x86_64 - Dirk Clemens - 2018-10-25  *****
 - MOVE 1/1 WBFS:xxx.wbfs -> YYYXXX_Title/YYYXXX.wbfs
!! wit: ERROR #80 [CAN'T CREATE FILE] in exec_move() @ src/wit.c#3576
!!      Can't create file: YYYXXX_Title/YYYXXX.wbfs
!!      -> No such file or directory [2]

The copy command does create the directories as intended.

Furthermore, the convert command could have a -d flag to specify the destination as well?

Hi,

I downloaded wit-v3.04a-r8427-mac.tar.gz and run the installer. I do see all files are universal binaries but unfortunately the system complaints that the files are broken and can't be run.

I then downloaded wit-v3.03a-r8245-mac.tar.gz as x86_64 and this works.

file shows arm64 as architecture for the v3.04a binaries where other universal binaries I have show arm64e.

According to this comparison it looks the current best format to use for storage.

Hi! I noticed that while the artifacts are there, the 3.03a source tarball is missing from here: https://download.wiimm.de/source/wiimms-iso-tools/

Hi,

I am hitting this assert trying to add a GC ISO.

wwt add --ignore --auto /home/nil/Downloads/Super\ Mario\ Sunshine.iso
*****  wwt: Wiimms WBFS Tool v3.02a r0 x86_64 - Dirk Clemens - 2020-07-31  *****
WBFSv1 #1/1 opened: /dev/sdb
 - ADD 1/1 [GMSP01] ISO:/home/nil/Downloads/Super Mario Sunshine.iso
!! wwt: ERROR #126 [FATAL ERROR] in wd_read_part() @ src/libwbfs/wiidisc.c#865
!!      ASSERTION FAILED !!!

Any ideas?

I was trying to batch rename some files and I noticed this problem. For some reason wit matches the ID4 instead of ID6.

wit MOVE -t -r . '%X'

***** wit: Wiimms ISO Tool v3.03a r8245 x86_64 - Dirk Clemens - 2020-08-03 *****
- WOULD MOVE 37/77 ISO:./Mario Kart Wii [RMCP01].iso -> Mario Kart Channel [RMCP01].iso
- WOULD MOVE 67/77 ISO:./Wii Fit Plus [RFPP01].iso -> Wii Fit Plus Channel [RFPP01].iso
- WOULD MOVE 68/77 ISO:./Wii Fit [RFNP01].iso -> Wii Fit Channel [RFNP01].iso

First of all thank you for these fascinating and useful tools!
Like the title says, when converting from purged wia to iso the date modified field is the date the new iso is created, and doesn't take the date from the wia it is converted from. I'm not sure if this is intentional or unavoidable behavior or not, but by contrast, wia --compression=none preserves the date modified timestamp by default, so I wasn't sure. This is using 3.04a-r8427. In both cases, --psel set to raw, no scrubbing.