> On Dec 18, 2021, at 11:43 AM, Darik Horn <dajh...@gmail.com> wrote: > > Jerome, > >> Did your repack include ALL packages included in the FloppyEdition not just >> i386. > > Yes, the repack contains 1,177 files. > > >> For example, VirtualBox and VMWare include FDNet as well as the set for 386s. > > Note that these things have empty categories in the official build, per below.
Technically correct. When the installer sees it is running on a VM, it includes a tag for that VM. That tag doesn’t have any correlation in the archive at present. But, when the installer sees it is running on VirtualBox or VMWare, it also throws in the Network Tag. Which includes FDNet. And possible other network based programs in the future. In theory, we could include a SOURCE tag that would then include the appropriate sources. But, that would needlessly bloat the FloppyEdition. All the sources are available on the CD/USB media and online. So, there is no need to waist space with them on the diskettes. The TAG system and hardware detection, may be expanded in the future to include things like Mouse, Joystick, Printer, etc. Each program is also tagged with it’s name. That way if someone for some reason wanted to extract just that program, they can. But the installer doesn’t use those TAGS either. I just remembered, there is one inefficiency in the archive that is not related to SLICER itself and would account for more of the %5 difference to ZIP. Basically, the RBE creates a fake package called FDINST specifically for machine that cannot support 386 or better programs. FDINST is part of FDNPKG. At present, the RBE includes two packages FDINST and FDNPKG. At some point, it will be told to handle that differently. At present, the files related to FDINST are in the the archive twice. It is not a SLICER issue, just something I haven’t got around to make the RBE build the archive more efficiently. > >> Does it make any accommodations for different hardware? > > Yes, the hardware detection logic is unchanged. > > >> Or just install everything wether or not it is supported by the target >> platform? > > In the RC4 repack, yes, the @LISTFILE method is equivalent to the > "slicer /g" switch. > > In the RC5 repack, no, it just does the same thing as "/g *". > > // > > Two unexpected results from the second experiment are: > > * The tarball method isn't worthwhile, despite using a solid archive format. > * The InfoZIP zipsplit method is better than the PKZip spanning method. This made me think of another thought… For maximum diskette capacity compatibility (and not requiring the end user to re-split an archive), slicer is using 59K slices. That size wastes only a little space on 360K,720K, 1.2M, 1.44M. It would also be workable on smaller sizes. But no-one is going to use a 120K diskette. It’s doubtful anyone will ever try to use 360K or smaller diskettes. But, if they are lucky enough to have the hardware and diskettes, a user may want to stick the release on a couple 2.88M diskettes. But, for your tests. They should be split at the same size 59K for user diskette compatibility. Also, you be sure to consideration the extra space required for the archiver. Some are quite large. Slicer gets around that problem. The first thing it extracts is GZIP which is uncompressed in the archive. Everything after that is Gzip compressed. That starts to get complicated when trying to just use a program like UNZIP. At nearly 200K for just the binary, it won’t fit on the 720k boot diskette. At present, that diskette has only 120K free and that may be reduced somewhat as well. There have been requests to add very useful programs like EDIT to that boot diskette. > > // > > In the official FreeDOS 1.3-RC5 floppy edition, %TTAGS% for things > like networking and virtualization are empty. When I manually unpack > FREEDOS.SAF, I get these categories and file counts: > > 186: 919 > 286: 1027 > 386: 1155 > 486: 1155 > 586: 1155 > 686: 1155 > 8086: 919 > 8088: 919 > AMBHELP: 11 > AMBREAD: 7 > APPEND: 14 > ASSIGN: 17 > ATTRIB: 11 > CALLVER: 6 > CGA: 807 > CHKDSK: 6 > CHOICE: 33 > COMP: 7 > CPIDOS: 27 > CTMOUSE: 34 > CWSDPMI: 14 > DEBUG: 17 > DEFAULT: 0 > DEFRAG: 7 > DELTREE: 11 > DEVLOAD: 9 > DISKCOMP: 7 > DISKCOPY: 19 > DISPLAY: 10 > EDIT: 10 > EDLIN: 40 > EGA: 1177 > EXE2BIN: 13 > FC: 26 > FDAPM: 9 > FDHELPER: 26 > FDIMPLES: 16 > FDINST: 5 > FDISK: 26 > FDNET: 20 > FDNPKG: 21 > FDXMS: 13 > FDXMS286: 12 > FIND: 27 > FORMAT: 13 > FREECOM: 48 > FREEDOS: 1177 > GRAPHICS: 11 > GZIP: 11 > HIMEMX: 10 > JEMM: 24 > KERNEL: 26 > KEYB: 10 > KEYB_LAY: 25 > LABEL: 13 > LBACACHE: 13 > MEM: 19 > MIRROR: 16 > MKEYB: 10 > MODE: 8 > MORE: 33 > MOVE: 19 > NANSI: 8 > NETWORK: 20 > NLSFUNC: 11 > PRINT: 7 > RECOVER: 7 > REPLACE: 9 > SHARE: 6 > SHSUCDX: 8 > SHSUFDRV: 12 > SORT: 21 > SWSUBST: 7 > TREE: 22 > UDVD2: 7 > UNDELETE: 11 > UNFORMAT: 12 > UNZIP: 11 > V8POWER: 144 > VGA: 1177 > XCOPY: 19 > ZIP: 18 Interesting. 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. As I’ve said before, I have no love for SLICER. It is kind of unique. But, it is also strange and of limited use outside the installer. There are many archivers that are well established, are easier to use and make more sense in 99.9% of all other situations. After all, I was not going to have any compression in the FloppyEdition for RC5. But once I finished fixing all the things the recent changes broke in the packages and RBE. I started making test builds to hunt down bugs. I saw the RBE is spitting out 12-14 diskettes for the 1.2 & 1.44 versions. That was way to many. So, about 2 days before the release of RC5 glued pass-through compression support into slicer. :-) Jerome _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
