> That starts to get complicated when trying to just use a program like UNZIP. > At nearly 200K for just the binary,
The unzip-5.52 binary in the repack is 50,229 bytes. Which versions are you using? Compare versus 27,814 + 39,910 = 67,724 bytes for slicer and gzip in FreeDOS 1.3-RC5. > But, for your tests. They should be split at the same size 59K for user > diskette compatibility. Why is this the right size? The current slice size of 60,416 bytes doesn't have a filesystem overhead, which seems intentional, but it isn't apparent how the end-user benefits. I'm getting better results with larger files by doing this... In a 1.44MB image, a default "format a:" has 1,457,664 bytes usable, less directory overhead and cluster slack of a few kilobytes. (eg: The FreeDOS boot disk.) If I tune the image with "mformat -c4 -r1 a:" and put one big file inside, then I get an additional 12,800 bytes of payload space, am guaranteed to get zero directory overhead and zero cluster slack, and get maximum throughput from the floppy drive. This savings won't always matter, but it is the reason why the ZipSplit build has one fewer disk than the Slicer build. > I don’t feel a couple percentage points better compression work the time and > testing to > make large changes to the FloppyEdition installer. But, it’s not like it > cannot be changed. This is reasonable given how late it is in the release cycle, and the gzip enhancement is indeed good. Nevertheless, this is a fun optimization job, and I'm getting slightly better results using standard tools. > There have been requests to add very useful programs like EDIT to that boot > diskette. This might be doable; I will look at it. _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
