> On Dec 18, 2021, at 4:19 PM, Darik Horn <dajh...@gmail.com> wrote: > >> 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?
The latest version we have 6.0. https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/unzip.html <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/unzip.html> It is a 1.6m package with Sources. It is 132K compressed without sources. The Binary is 192.5K uncompressed. It is not 8086 compatible and requires DPMI. So That is another 20.8K. So, just for the current UnZIP and CWSDPMI binaries about 220K is required. > Compare versus 27,814 + 39,910 = 67,724 bytes for slicer and gzip in > FreeDOS 1.3-RC5. > I think that could be a little mis-leading. For this reason… At present, both UnZip and Gzip are installed on 386+ machines with the FloppyEdition. So, their overall size is not very important. What does matter is the amount of space required on the boot/install diskette. Whether UnZip needs 220k or 50k, that is still bigger than 27k needed by Slicer. Gzip, is not on the boot disk. It is first in the archive and extracted by Slicer. Slicer then begins using it automatically. So, the size of GZip is not relevant. Actually, a few kbytes could be squeezed out of the archive by splitting Gzip into 2 pieces. The first piece would be just the 8086 EXE. The second piece could then be compressed with the 386 version and everything else in the current Gzip package. > >> 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. In Part, the RBE only needs to create one Archive (using DOS), then it can just spread it out across the different media quickly using Linux. It is also less code in the RBE. The User benefits by not only getting a single 1.44mb version. The 59k slices spread nicely across the different media. 720k only 3k remaining. 1.2mb only 4.5k remaining. 1.44mb only 6.5k remaining. Intent is also to eventually do a little restructuring of the boot disk and installer to allow provide 360k version as well. But, that is an extremely low priority. It would have around 1-2k free space remaining. The smaller slice size also allows the usage of not 100% healthy disks that have had bad sectors mapped out. You would need to know how to do that and manually copy the slices. But, it is still an option. > > 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. I think the level of compression provided with pass-through Gzip is “good enough”. An overall performance is on par with MS-DOS. A recent test install of MS-DOS onto my Pentium-Pro took roughly 5-6 minutes to copy and extract the DOS files from floppy. Installing RC5 from floppy to an Intel Atom based Netbook took about 7-8 minutes to extract the 5 diskettes of FreeDOS packages. There are numerous hardware difference between the two machines. So, it was not a benchmark speed test. But, does show it takes a similar about of time per disk. There would need to be a very large improvement in compression to make it worthwhile in adding additional overhead or just reworking the portion of the RBE that creates the FloppyEdition. The RBE was a lot of work to create. It fully automates the creation of a release. Basically, anyone can follow the directions in the wiki and create a HOST VM for the RBE. Use git to checkout the RBE. Then run install as sudo/superuser to configure the system automatically. Once that is done, to create a release… type “make” and hit enter. Go to lunch, come back you’ve got a FreeDOS release with the latest packages, in all the various formats that is ready to send out the door. By no means is the RBE perfect. This is version 3 and it may have a couple minor issues that I need to look into. But, it makes creating a release easy, consistent and reliable. I think anyone who’s really into FreeDOS should try running it sometime. By default, it runs in non-verbose mode. But, change it to verbose, you will see gigabytes of text scroll by. And that is still only a summary of everything it needs to do to push out a release. It is kind of amazing to watch. I know of only one other person who uses the RBE. They use it to create a custom spin of FreeDOS that includes some Assistance software. > Nevertheless, this is a fun > optimization job, and I'm getting slightly better results using > standard tools. Have fun squeezing bits. :-) You could always create a spin yourself. Maybe include extra stuff, like network programs or games or something. >> There have been requests to add very useful programs like EDIT to that boot >> diskette. > > This might be doable; I will look at it. :-) Jerome
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
