The AppCompactor is a good idea, but it's missing a big opportunity by not processing text-based files as well as binary files. Many configuration files, some of which are XML-based, contain excessive white spaces because it makes them easier for a human to read, even though most of us will never open them manually. It makes no difference to the programs if excessive white spaces and comments are taken out. Some other common files, like README files, can be deleted entirely without affecting program functionality. The only drawback to this approach is that the changes would be irreversible without backing up each file that was changed. Also, some of the comments in these files could contain license info, and it would probably upset some people if this data was automatically removed by another program.
New: Kanri (Oct 9, '24), Platform 29.5.3 (Jun 27, '24)
1,100+ portable packages, 1.1 billion downloads
No Ads November!, Please donate today
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
What about CRLF?
Doesn't that negate white space?
then you can simply edit the bat file for the start of the upx, sure you can compress also all the text and the bat files too.
Dont be surprised when nothing works thereafter.
Otto Sykora
Basel, Switzerland
Compressing and filtering aren't really the same thing. Like I said, a lot of configuration files are XML-based and they work exactly the same if you cut out useless white space and comments.
this means removing 'white space' on character level, well you cant really seriously expect anybody today to deal with things like that. Removing redundant information is basic aim of compression, so everybody would try to do it properly and this would lead to broken functionality.
So editing text files, scripts and similar in this way was not very on already in times when we did run all from floppy. The saving on space is that little it simply makes no sense. There is no point in making a 3kb file to become 2kb long as we have today no media which will be able to distinguish those two sizes in some useful way. (remember file system, sectors, clusters!)
Well exception: when you print such file you will use more paper, but how often we do this?
Otto Sykora
Basel, Switzerland
Maybe it only saves a few kilobytes per file, but I've saved more space with this method than actually running AppCompactor. Can someone tell me an example of AppCompactor saving megabytes of space? With memory so cheap nowadays compressing to save space is more likely an action of someone with OCD.
It's unlikely we'd ever do anything that modified config files as this can mess up some programs (some need that whitespace... and most will add it back in the next time they're used anyway). Plus, as mentioned, this will usually only save a few KB for a whole app.
The PortableApps.com AppCompactor is used on nearly all our software and saves a LOT of space on many apps (this is also why if you use it again on any of our apps, it won't save any more space... it's already been done). GIMP, for example, goes from 36.5MB to 18.9MB by using the AppCompactor. OpenOffice.org is larger and the AppCompactor saves even more space on it.
Sometimes, the impossible can become possible, if you're awesome!
>Maybe it only saves a few kilobytes per file, but I've saved more space with this method
Otto Sykora
Basel, Switzerland
It depends on the executable it's compressing.
If you've for one which has loads of uncompressed resources in it (e.g. a few bitmaps, or a large stringtable), it'll compress down a lot more than one without these, and consists of nothing but executable code.
(That's just an example, mind)
I'd agree with your comment about it being a bit pointless in some respects though - with the smallest size USB sticks normally being being 2GB+ (although 1GB can still be found), saving a few MB doesn't make any significant difference, and the saving can be a pathetically small percentage of the storage medium.
However, a bigger impact of compressing is probably the speed at which it can be pulled off the drive and uncompressed (i.e. reading a small file and uncompressing can be a bit faster than reading a large file via USB)
though, XML is meant to be something of a saviour and can operate in this way.
Also, why when I click login in below someone's name it posts me at the top?
but look at all those xml and ini files etc.
Only few are bigger then 32kb. And often those which are, contain base64 encoded binary data beside the script so here some removal of spaces will not help.
In the rest of the xml files for example, if you shift there all text lines to the left to leave out empty spaces the script might still work, you might save few percent of the few kilobyte the file legth. This will save nothing since space on drive will occupy 32kb regardless of the size of such file. A file has to occupy one cluster minimum and this is with common fat32 32kb so far.
So this is the fact why I can not get the point of making scripts unreadable, where there is zero advantage on the other side.
Otto Sykora
Basel, Switzerland
FWIW, FAT32 cluster sizes (under windows) are 4K (or less) by default - until you get a storage device over 8GB - in which case, you probably don't care about the minimal space saved.
'smaller' partitions will have even under fat32 4k, by some mistake I managed even to have 24gb partition with 4k clusters, believe me this is fun, files appear 4x times after scnadisk etc.
For some reason even two of my 16gb sticks were formated by original windows xp to cluster size of 32k, thought this should happen with partitions over 32gb.
Other have 8k and 16k clusters, the defoult should be 16kb for a 16gb partiton. Less then that will lead to problems sooner or later.
Otto Sykora
Basel, Switzerland
With the proliferation of increasingly larger capacity portable media, does filtering out a few text files really have that much of an impact on how much size is saved? It's not like we're trying to fit everything on a floppy disk or 16MB thumb drive anymore.
To me, it's not worth the effort, brain bytes expended in building/coding something to strip "extra" characters out of text files, and isn't worth the downside of possibly having illegible/unusable files.
The only extra file that bugs the hell outta me is "Thumbs.db"...
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
Thumbs.db is automatically filtered out by the PortableApps.com Installer. So you won't see it in any of our appsor any PAF apps by 3rd parties anymore.
Sometimes, the impossible can become possible, if you're awesome!
I have a "build file" that automatically deletes it as well
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
Glad it's filtered out nowadays.
That was just a side comment on a file that really bugs me to no end, that's all. Not just in portable app packages, but anywhere. (They KILL ME on LAN shares *sigh*).
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!