Looking for Extraction tools for 7z and Shrinkler

[Brian]

I'm using LZX to pack different kind of data onto a floppy and use UnLZX (also need to fit the disk) to unpack the data. I know 7z can give me roughly 60-100KB better compression, something I'd gladly take since I have more I'd love to cram onto the thing, so I wonder if there exist a tiny standalone un7z tool? Checked Aminet but the programs I find there usually req. a 100+KB library to work and ultimately result in a bigger package (archive+extractiontool+libs).

On a sidenote, does there exist any small decruncher for Shrinkler compressed programs?

Both need to work with 68000 without FPU.

[chris]

Untested: http://www.cy2.uk/tmp/7zdec_os3.lha

[Brian]

I'd love to test it but the archive is corrupt so can't extract the file, any chance you can upload it again?

It seem to be a bit on the large side for an extraction tool (and double the size of the PPC version) but if it's not dependent on some external library it might still help me save some space and every KB counts... fingers crossed it'll be double digit which would be just awesome.

[Britelite]

On a sidenote, does there exist any small decruncher for Shrinkler compressed programs?

Doesn't Shrinkler itself work for this purpose? And the archive comes with source code for the decruncher, so you could basically also make your own tool.

[Brian]

Doesn't Shrinkler itself work for this purpose? And the archive comes with source code for the decruncher, so you could basically also make your own tool.

The thing is I'd like to revert back to the original executable file from a Shrinkler crunched file. You'r right there is a source in the archive but since I can't code it doesn't really help me.

[chris]

I'd love to test it but the archive is corrupt so can't extract the file, any chance you can upload it again?

Ah, it probably isn't corrupt - For quickness, I compressed it using a Linux LhA which uses a compression method the Amiga command-line LhA doesn't support.  You should be able to extract it with UnArc.  Otherwise, I'll re-compress and re-upload it this evening.

It seem to be a bit on the large side for an extraction tool (and double the size of the PPC version) but if it's not dependent on some external library it might still help me save some space and every KB counts... fingers crossed it'll be double digit which would be just awesome.

That's about as small as it will get, I might be able to toggle some optimisations but it's unlikely to make much difference.  It's the decompression tool from the LZMA SDK, ie. the bare minimum.  It's less than 80K.

edit I suppose you could PowerPacker the 7zDec executable

[Pat the Cat]

I'm using LZX to pack different kind of data onto a floppy and use UnLZX (also need to fit the disk) to unpack the data. .
On a sidenote, does there exist any small decruncher for Shrinkler compressed programs?

---

Both need to work with 68000 without FPU.

Here's an oddity - different compressor programs vary in efficiency on different data types.

I reckon, 7z, even with a library, will do a better job. dear old Lentle-Ziff-Huffman isn't what it used to be, and that's what most Amiga crunchers are based around.

If you setup all your files at once, so they end up as one big file, that will cut a lot of redundancy out, for files of a similar type. Especially if they are not too big to begin with.

One datatype that will NEVER crunch is raw fax code. It's already 2-1 compressed or better to begin with.

And finally, do make it clear to the end user that they have to decrunch the stuff TO somewhere. A bit of text to explain how to use, in a readme.txt file. That's worth it. It will take up a couple of disk sectors (which is a good way to think about using floppy disks efficiently) but don't rely on the person with the disk to have a clue what to do with it.

I hope one day somebody codes up IFS compression, but that's not going to happen in a hurry. It's not exactly ideal for lossless, which is what you need for executables. It's a bit fuzzy.

[Brian]

Here's an oddity - different compressor programs vary in efficiency on different data types.

I reckon, 7z, even with a library, will do a better job. dear old Lentle-Ziff-Huffman isn't what it used to be, and that's what most Amiga crunchers are based around.

If you setup all your files at once, so they end up as one big file, that will cut a lot of redundancy out, for files of a similar type. Especially if they are not too big to begin with.

One datatype that will NEVER crunch is raw fax code. It's already 2-1 compressed or better to begin with.

And finally, do make it clear to the end user that they have to decrunch the stuff TO somewhere. A bit of text to explain how to use, in a readme.txt file. That's worth it. It will take up a couple of disk sectors (which is a good way to think about using floppy disks efficiently) but don't rely on the person with the disk to have a clue what to do with it.

I hope one day somebody codes up IFS compression, but that's not going to happen in a hurry. It's not exactly ideal for lossless, which is what you need for executables. It's a bit fuzzy.

Before when I checked I get about 60K better compression with 7z than LZX but last time I ran it I got about 100K so don't know why last time was any better... however most unpackers rely on 130+KB libraries plus the unachiver so thus far I've not found something that rivals LZX when it comes to data on a single floppy.

In short I try to put all six OS3.1 floppys onto a single DD floppy and have that work as a standalone install disk that you can use first time setting up the HDD to install. I want it to work on 68000 and requier no more than 1MB memory (atm I uses less than 768KB). I've optimized the heck out of it and I'm at where there is nothing left I can do that would save space (that I'm willing to do). Except if I can get the already compressed files on the floppy to take even less space. Replace LZX archives with z7 and replace Implode crunched files with Shrinkler. There's space to be saved but it also depend on the size of the unpacking tools (Deplode added only 900B to the LZX archive it's in) and UnLZX is crunched to only 10KB and need no libraries... something I've not seen anything rival until Chris's post.

[paul1981]

If you still use Imploader just remember the 040/060 problem:

http://aminet.net/package/util/libs/explode-7

[Brian]

If you still use Imploader just remember the 040/060 problem:

http://aminet.net/package/util/libs/explode-7

The Imploded crunched files have internal lib so no external lib required and that doesn't seem to have issues with 040/060.

[Pat the Cat]

In short I try to put all six OS3.1 floppys onto a single DD floppy and have that work as a standalone install disk that you can use first time setting up the HDD to install. I want it to work on 68000 and requier no more than 1MB memory (atm I uses less than 768KB). I've optimized the heck out of it and I'm at where there is nothing left I can do that would save space (that I'm willing to do). Except if I can get the already compressed files on the floppy to take even less space. Replace LZX archives with z7 and replace Implode crunched files with Shrinkler. There's space to be saved but it also depend on the size of the unpacking tools (Deplode added only 900B to the LZX archive it's in) and UnLZX is crunched to only 10KB and need no libraries... something I've not seen anything rival until Chris's post.

Without commenting on the lawfulness of the chosen data... Which would be perfectly OK if the person using it has an actual ROM chip somewhere in their collection. (Will Amiga Inc ever sue Mac over that, I wonder? Seems fair, it was the other way around in the past). Anyway...

That is your problem, doing single fles rather than a single joined up one. When you use any data sector, any unused space is wasted on the last sector. That is why arranging the data into a single set, then compressing that set into a single file, is going to save you space.

The snags are two fold - first, you need a fast Amiga with lots of fast RAM to set it up - second, your compressor has to first uncompress the archive, the correctly chop it up into single files and copy them to the HDD. You have set no margin for error on doing that on a 1MB single floppy with a HDD attached. But, I admire your thoroughness in pursuing that goal - trying to get it universal.

Here's a simpler way - do it as 2 disks. One as the uncruncher. The next one, when booted, splits up the decompressed file, makes a new set of sub directories, and copies all the split files into the right places. That might just work, and give the end user a nice front end when setting the thing up. The snag is, the decrunching has to happen on one file, which has to be gradually read in, decompressed, and copied to the hard drive. Very demanding.

It does mean two boots from different floppies, but it gives both you and the end user some control over how their hard drives will be setup. That might not seem an issue. Well, it is if the end user is running a real 1.3 Amiga. Having a warning saying "this isn't going to work without a ROM change" would be very helpful to noobs with Amigas, for instance.

Even if you don't for the single file option (it is very challenging), a second floppy for excess data and setup might be required anyway. For files crunches that won't fit, and also for the setup. It would save one reboot, so might be a bit quicker for the end user.

[puppypc]

Is it possible, and if so have you tried to remove files that you won't need? (e.g. any unused locales, screen modes, etc)?

[paul1981]

The Imploded crunched files have internal lib so no external lib required and that doesn't seem to have issues with 040/060.

Ah okay, it's been a while since I used it (1990's)!  I'll have to play around with it again at some point. So there must be a choice then between external library (explode) and internal decompressor (inside executable)... and if you have more than one crunched executable then the library would be more space efficient.

So anyway, you're trying to squeeze the OS3.1 disk set onto just one floppy? It certainly sounds ambitious. How small have you gotten it up to yet?

[Brian]

Is it possible, and if so have you tried to remove files that you won't need? (e.g. any unused locales, screen modes, etc)?

Ow I have to do that or it wouldn't fit for sure. Almost all Locals and printers as well as a good chunk of fonts and a few other things. Removed duplicate mountlist and icons to copy/create and reposition them later. Created a custom install script. And crunched/packed just about everything left.

Ah okay, it's been a while since I used it (1990's)!  I'll have to play around with it again at some point. So there must be a choice then between external library (explode) and internal decompressor (inside executable)... and if you have more than one crunched executable then the library would be more space efficient.

So anyway, you're trying to squeeze the OS3.1 disk set onto just one floppy? It certainly sounds ambitious. How small have you gotten it up to yet?

I only have HDToolbox Imploder crunched since I don't want it to be crunched on the HDD and I can use deploder for that and having the imploder lib in the exe doesn't add much to the filesize so more spacesaving that way. UnLZX is Shrinkler compressed and doesn't need any library. Rest is either in LZX archive or can't be crunched/packed due to the nature of the file (such as startup-seq, a readme file, L:fastfilesystem)

It fits right now but as said to puppypc I've had to remove some nonessential files, but I want that at a minimum so any space I can save goes towards making it more complete again.

Without commenting on the lawfulness of the chosen data... Which would be perfectly OK if the person using it has an actual ROM chip somewhere in their collection. (Will Amiga Inc ever sue Mac over that, I wonder? Seems fair, it was the other way around in the past). Anyway...

That is your problem, doing single fles rather than a single joined up one. When you use any data sector, any unused space is wasted on the last sector. That is why arranging the data into a single set, then compressing that set into a single file, is going to save you space.

The snags are two fold - first, you need a fast Amiga with lots of fast RAM to set it up - second, your compressor has to first uncompress the archive, the correctly chop it up into single files and copy them to the HDD. You have set no margin for error on doing that on a 1MB single floppy with a HDD attached. But, I admire your thoroughness in pursuing that goal - trying to get it universal.

Here's a simpler way - do it as 2 disks. One as the uncruncher. The next one, when booted, splits up the decompressed file, makes a new set of sub directories, and copies all the split files into the right places. That might just work, and give the end user a nice front end when setting the thing up. The snag is, the decrunching has to happen on one file, which has to be gradually read in, decompressed, and copied to the hard drive. Very demanding.

It does mean two boots from different floppies, but it gives both you and the end user some control over how their hard drives will be setup. That might not seem an issue. Well, it is if the end user is running a real 1.3 Amiga. Having a warning saying "this isn't going to work without a ROM change" would be very helpful to noobs with Amigas, for instance.

Even if you don't for the single file option (it is very challenging), a second floppy for excess data and setup might be required anyway. For files crunches that won't fit, and also for the setup. It would save one reboot, so might be a bit quicker for the end user.

About legal... as long as I have it for personal use and for friends and others who own the WB3.1 I see no legal problems. Sure it might eventually leak onto the internet but that won't be my doing.

I use LZX merge option and it compresses it nicely... there's actually only about 1.2KB to save from putting everything into one uncompressed archive before compressing it and I decided that the extra memory requirement and decompression time wasn't worth it. That said 7z would compress it way harder so I'm still hopeful it'll be the next space saving step.

Everything fits way too easy onto a HD floppy (very first incarnation of this project) or 2 floppys... I've created a second Extras disk just to make the installation complete again and that one also includes big hdd support, pfs, sfs, , 060 libs, pcmcia cf support, magicwb and a few other addons. But it's optional "extras"... I want the challenge of making it a standalone 1 disk option mainly cause one of the reasons for this project was to remove the need for swapping floppies and another reason was so you don't have a corrupt disk X of 6 preventing you from completing the installation.

[Brian]

7zdec helped me save a bit more space by allowing me to use 7zip for the archives instead of LZX. Big thanks to chris!