First of all, thanks a lot for KZip! It sure thing is a great tool for creating JARs for J2ME-phones. But... ;)
It seems that Series 60 (n-Gage QD, 3650, etc.) don't like it when the KZip leaves files uncompressed. E.g., PNG files. And WTK emulator doesn't work either when it tries to access such files. I just get
JAR error: Code table empty
JAR error: Invalid input bits
Would it be possible to have some kind of a switch in KZip that forced KZip to compress all files, even though the result would be bigger than the original file? Or am I missing something here? ;) Any suggestions?
Thanks!
Awesoken at
I would suggest you redirect your complaints to the makers of those products. I'm not interested in hacking up KZIP with silly options to support non-compliant software.
Saucjedi at
Mmmmm, I have never find such problems developing for S60 phones (7650 and 6600 have been my main targets, but QA assured me that it worked even on N-Gage...) , check well your parameters.
I'm afraid Ken is right: it's the phone makers fault in 99% of the cases... we must live with that and thank Kzip and Ken when it performs well, and blame Nokia & cia when it doesn't...
Good luck on your endeavors!
counting_pine at
Does it happen with other zip programs? I would have thought that choking on any uncompressed file would be too big an issue for them to ignore,especially when image files tend not to be compressable.
vhelin at
counting_pine said
Does it happen with other zip programs? I would have thought that choking on any uncompressed file would be too big an issue for them to ignore,especially when image files tend not to be compressable.
I checked by compressing the game using WinRAR (Zip mode), and it worked. The game just halts when it begins to load a file that's just stored into the KZipped JAR... Could it somehow be that it's not the PNGs, but it's that one 22 byte file I also load (it's stored as well)? Does KZip handle very small files differently?
I'm too busy at the moment to investigate this further, but it really sucks that all these phones are so full of trouble. Anyway, KZip really rules when it comes to Series 40 phones, and that's where it's needed. S60 phones support big JARs anyway...
masterlee at
Btw.: Die you know what compiler to use to compile for UIQ Phones?
psi at
Hi,
I just faced the same Problem. Before someone tells me to go blame the phones manufacturer: I like kZip. I used it alot already. And I will still continue to use it ;-)
I just wanted to point out that it doesn't help in knowning whose fault it is. Companies like Nokia wouldn't even listen. And if they would, you still can't use kZip on such a JAR - there are too many of those buggy devices out there already, so these users wouldn't be able to run the program.
Sure it's no bug in kZip, but in the phone - so an option to compress all files would be a workaround. Many people use kZip for J2ME programs because often you need to save those 10 bytes to get right below the maximum JAR size required.
Iif Ken decides to add such an option - great! If not, well, no big deal either :-)
Greetings!
counting_pine at
I'm not sure I understand what's happening exactly, but have you tried adding the problem files to the archive using a different zip program, e.g. 7-zip? I don't believe that KZIP is doing anything wrong, but perhaps 7-zip will make files that the phone might be happier with?
psi at
I didn't try with 7zip because I stopped using it quite a while ago (it created too many non-working JARs).
Not sure whats happening exactly, but I compared the standard JAR compression with the one kZip generates. The file which fails loading is a small 71 byte file. Both programs deflate the file - kZip down to 67 bytes, and JAR even down to 66.
The JAR is not corrupted because I have no problems using it on windows, but Nokia phones fail to load the file when using kZip.
Awesoken at
Bah, humbug. I caved in and added a "no store" (/ns) option to KZIP. Let me know if this fixes the problems with those cheesy Nokia phones.
Metasheep.com at
I've found the same problems with certain kzipped files on other phones as well as the emulators. Also, I get errors with those files with the jar tool being developed in this thread.
A zip with some of the error files is at http://www.metasheep.com/files.zip
I just tried it with the /ns option and still get the errors.
Awesoken at
Thank you for the file samples. I'm afraid this looks like the Zlib 1.2.1 distance table bug. Zlib 1.2.1 (and perhaps some versions previous to it) incorrectly exit with an error when it detects an empty Huffman distance table. KZIP and PNGOUT will produce these "offending" files even though they are perfectly valid streams, according to the official Deflate spec. You can fix the problem by upgrading to Zlib 1.2.2 or above. You should see this in the Zlib release notes: "Fix a bug when decompressing dynamic blocks with no distance codes". That's the bug I'm talking about.
I added a new option to both KZIP and PNGOUT: -zl121
Here are some examples:
kzip -zl121 files.zip
pngout -zl121 tr_venus.png
Using -zl121 should generate a stream that is readable by Zlib 1.2.1. Unfortunately, using this will add a few bytes to some files - there is no way around it. I have chosen to leave this workaround undocumented for now.
I made a little chart comparing how -ns and -zl121 affect file size:
If you're worried about the size increase when adding a code to the Huffman distance table, why not turn it to your advantage - add one or more length codes to the Literal Huffman table, and you can use RLE to improve the compression.