BATCOMP compression

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Apr 13, 2010
190
2
57
The Hague
#1
I was surprised to learn that BATCOMP does not remove comments, empty lines and leading/trailing whitespace before compression. In my case that in itself produces a compression of about 50%. On top of that BATCOMP manages an other 40%. I would suggest you add the removal of irrelevant text.

I would also suggest you add to the docs the caveat that using BATCOMP breaks the `gosub "<file.btm" label ` functionality because it alse garbles the labels. Perhaps the labels could be spared in a future release?

Again, thanks for a wonderful product.
I use it dayly.

DJ
 

rconn

Administrator
Staff member
May 14, 2008
10,096
85
#2
Please add suggestions to the feedback forum -- suggestions posted here will rarely be saved & implemented.

BATCOMP calls the internal zip library to do the compression & encryption. Removing comments, empty lines, etc. would require some considerable preprocessing (& creating temporary files). IMO it wouldn't be worth the effort to save $0.0001 of disk, but if enough people vote for it I'll consider adding it to a future version.
 
#3
How is the encryption key to be specified? Since V14 two options of the BATCOMP command are no longer in HELP:
/E encryption key
/K kill comments
The latter is just for compression efficiency; I concur it is no longer significant. However, the main purpose one would now use BATCOMP is for encryption.

BTW, am I correct that it was in V14 that the internal, generic compression library replaced the custom compression that had the ability to strip comments?
 
#4
BTW, can one use the BATCOMP command of V13 to compress a V16 file?
The compression ratio may be better (esp. if lots of comments, appropriate for a file for distribution), or worse - improved compression algorithms.
 
Apr 13, 2010
190
2
57
The Hague
#5
Please add suggestions to the feedback forum -- suggestions posted here will rarely be saved & implemented.

BATCOMP calls the internal zip library to do the compression & encryption. Removing comments, empty lines, etc. would require some considerable preprocessing (& creating temporary files). IMO it wouldn't be worth the effort to save $0.0001 of disk, but if enough people vote for it I'll consider adding it to a future version.
Which effort is that?

Code:
TPIPE /input=%input /output=%output /simple=12 /simple=10 /grep=5,0,0,0,0,0,0,0,"::.*"
DJ
 

rconn

Administrator
Staff member
May 14, 2008
10,096
85
#7
How is the encryption key to be specified? Since V14 two options of the BATCOMP command are no longer in HELP:
/E encryption key
/K kill comments
The latter is just for compression efficiency; I concur it is no longer significant. However, the main purpose one would now use BATCOMP is for encryption.
You don't specify the encryption key; TCC does that internally.

BTW, am I correct that it was in V14 that the internal, generic compression library replaced the custom compression that had the ability to strip comments?
Yes.
 
Apr 13, 2010
190
2
57
The Hague
#10
Which effort is that?

Code:
TPIPE /input=%input /output=%output /simple=12 /simple=10 /grep=5,0,0,0,0,0,0,0,"::.*"
DJ
Let's leave that (obvious) exercise to the reader. Your point is ... ?
If effort is your point and REM's in compound commands are difficult, by all means skip them.
We must have covered at least 99% by now?

Cheers, DJ
 

rconn

Administrator
Staff member
May 14, 2008
10,096
85
#11
BTW, can one use the BATCOMP command of V13 to compress a V16 file?
The compression ratio may be better (esp. if lots of comments, appropriate for a file for distribution), or worse - improved compression algorithms.
The compression ratio is far, far worse in v13, unless you (1) only have really small batch files (i.e., the type that make no sense to compress), or (2) only have batch files comprised almost entirely of comments and blank lines.
 

rconn

Administrator
Staff member
May 14, 2008
10,096
85
#13
When the purpose is not compression but hidiing code, and you want to use unique keys for each user (like TCMD registration keys), would v13's encryption make sense?
Yes, if you only need to hide your code from your 5-year-old. The v13 (actually 4DOS v3!) "encryption" is extremely simplistic, and you could find a number of decrypters with a quick web search.