wrathma: Many questions!
wem-packer: Why are both "oggre_enc/oggre_dec" binaries needed? Also, how are they 9KB larger than the original files?
In the original "ww2ogg" package, there is another "packed_codebooks.bin" file. Could the lack of this cause problems in some cases?
There is a 64-bit version of this program on GitHub, I won't link it directly, find it and take a look, you'll get the hang of it!
There is also a "
revorb" project, isn't that better than "ww2ogg"? Instead of the HDiff package, would xdelta3 be a worse solution? (it runs natively on XP too.) HDiffPatch XP
issues from GitHub. (Two x86_64/i686 XP binaries found the posts.)
Is there a way to configure the program, especially "hdiffz", to use very little memory when creating a diff file? (It should comfortably fit within the 512MB upto 1-2GB memory limit.) It is true that when applying a diff file as a patch, in principle a lot of memory is required.
You're obviously asking, why XP?? If everything is true, around 2005 (or earlier?) games that have *.wem files were released and regarding these files, it would be possible to make the repacks publishable/archivable back to XP.
There's a bug in the 32bit version! The "hdiffz" binary file in it is 64bit!
Yesterday, I managed to make all the binaries run on XP. Although, a full native XP-compatible HDiff/patchz binaries would be better case/idea.
In the case of v4.8.0, the "hpathcz.exe", with the simple NT6.0 -> NT5.1 trick, runs smoothly, while the larger "hdiffz.exe" file, I had to tinker a bit more with CFF Explorer + 3 extra DLL files required, to run it.
In the case of v4.11+ versions, the latter situation is present for both files.
The only task that remains to be solved is to create an EXE file that can be run natively under XP by the GO-compiler. (Why does this require the "bcryptprimitives.dll" file?)