A year or so ago I wrote out some instructions detailing how to make SignatureTool.jar work in Unix type systems. Soon after I got word that somewhere around JDE 4.6 or DE 4.7, RIM actually fixed the mistake in the sigtool. Sadly they missed one.
If you attempt to sign a
.cod file larger than 64KB (ie: contains sibling
files or child files or whatever files) then you will likely get a file
created in your current working directory that looks something like
kd8m34jkf/my_lame_app-1.cod. When you load the file to the device it will
result in an error of some sort. The fix for this is relatively simple.
Read on for the details.
Edit class file
Go back and read my other post for instructions on extracting the jar file and for packaging it up again. I’m going to leave out some details here since they are covered previously.
Note: this is based on the SignatureTool.jar file from JDE 4.7. I have not verified that this procedure is the same for other versions of the JDE.
We will use good old ClassEditor again.
q.class and change string constant at index 253 from a back slash to a
Pam May 10th, 2010
Has someone tried it with JDE 5.0? There’s no line 253 like the one in the image. In fact there’s no line with a back slash at all.
jiGGaK May 10th, 2010
Maybe this has already been fixed in 5.0? You can tell by simply signing a large .cod file. Make a simple application and compile in several larger resources (>100Kb). Then use the signature tool to sign your .cod file.
After you sign, if there is a file with a random string of characters and a backslash in the name then it is still broken. In which case it’s possible that another .class file contains the hard coded backslash.