Hi Travis, > On Nov 11, 2021, at 10:37 AM, Travis Siegel <tsie...@softcon.com> wrote: > > I have never used slicer, so can't comment on it. > I wouldn’t expect you to use it. In almost every case, there are other utilities that are in common use. And/or, better suited to a task.
Slicer was created specifically to make the Floppy Edition happen. Lets not forget that prior to 1.3-RC3, there was no Floppy Edition. I decided it was better to have the floppy version without compression. As opposed to waiting until compression was fully supported. > However, I have used rar for years, and I've never found a task it can't be > made to do with proper command line parameters. If you only want a specific > file extracted, it's easy enough to tell it to use that file only, (or a > range of files if that's your want). > Like I said in in earlier post, other utilities could be used to sort-of mimic what slicer does. But, it then it adds a lot of complexity to the installer and result in multiple passes through the archive. Or, at minimum require having the installer keep numerous lists and try to splice them together to feed the extractor. Off the top of my head, your looking at some unknown combination of 8086,186,286,386,486,586,686 + Real,GenericVM,DOSBox,VirtualBox,VMware + MCGA,CGA,EGA,VGA + Network/not + UserLanguage At present, some tags make no difference. While others do. And others (like maybe VESA) may be added at a later date. How can that be organizes in a structure that does not require the installer to calculate lists, does not duplicate files and does not require multiple passes (diskette 1, diskette 2, diskette 1 again, ….)? > It can also extract with or without file paths. It's been a while since I > compiled my own copy of unrar, but I honestly don't remember it being all > that large, it was certainly considerably smaller than the rar program > itself. I don't (currently) have a working stand-alond dos machine, but I > think dosemu can help. I'll do some digging/testing, and see if I can help > here, it's always better to have smaller distribution media, shorter download > timesequates to less time/money spent installing, and sometimes, that makes > all the difference as to whether someone goes with your solution, or chooses > something else. If anything, I've always felt freedos doesn't include enough > in the way of programs for folks to get started, so if we can reduce the size > of the distribution media, then that will allow for including more programs > as well, and that should make everyone happy. > I agree that smaller would be better. And assuming slicer is not replaced with another method that can do the same job, support for compression will come to it eventually. It is not a very complicated thing to add. It would probably only require a couple dozen lines of code. However, testing will be much more time consuming. Unfortunately, the list of other things to-do is long and many are of much higher importance. :-) Jerome
_______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
