Re: [Freedos-user] Ontrack Disk Manager
Ontrack is a super nice contribution by Kroll because it is important software for old motherboards. In order to make Ontrack better conform with FreeDOS licensing rules, I removed most of the non-free software in the dist package and put it here: * https://drive.google.com/drive/folders/1SuBdp6TmXmWj2GYFvDfnxv8r6gQr9UhQ?usp=sharing Changes from the upstream release in the ontrack-9.88.0-freedos.ima.xz file are: 1. The DMZIP1.EXE and DMZIP2.EXE files are combined and repacked as the DM.CAB file. This reduces distribution size from two floppy disks to one floppy disk, but the actual application software is unmodified. 2. DR-DOS system components are replaced by FreeDOS equivalents. 3. The AUTOEXEC.BAT file is accordingly rewritten. 4. The SPLASH.EXE utility is compressed by UPX. 5. The DDO is preinstalled to the floppy boot area so that the FreeDOS kernel does not complain about LBA translation errors involving large disks and/or large partitions at boot time. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Ontrack Disk Manager
Regarding this old ticket: * https://sourceforge.net/p/freedos/bugs/211/ FreeDOS 1.3 is compatible with Ontrack v9.57 and Ontrack v9.88. I tested these disk overlays on a 486 with AMIBIOS 2.02, which has the 504 MB addressing limit. Kroll released their Ontrack software to the retro computing community at zero-cost per: * https://www.philscomputerlab.com/ontrack-disk-manager.html ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Floppy Installer repack of FreeDOS 1.3-RC5
> 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
Re: [Freedos-user] Floppy Installer repack of FreeDOS 1.3-RC5
Jerome, > Interesting. There are other compression methods to try. For example, lzma, > bzip2, arj, etc. These codecs were excluded in the first repack series. Results were: 1. LMZA1 Not significantly better than ZIP while using a dictionary size appropriate for small-memory machines. And 16-bit utilities are not in distro. 2. ARJ Belov's implementation from http://arj.sourceforge.net/ has performance similar to ZIP. I didn't try the official non-free encoder because I couldn't get a license for it. 3. BZIP2 Way too slow. > Overall, I think using GZip for the pass-through compression works well > enough, supports 8086 and uses little space. Deflate32 as implemented by GZip or InfoZIP is definitely the sweet-spot for baseline installation targets, especially with zopfli post-processing. If I do a third series, then I will try LZ4 and multivolume 7Z, but I'm also tempted to implement a RAR2 encoder for unrarlib and/or libarchive. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Floppy Installer repack of FreeDOS 1.3-RC5
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. > 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. // 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 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Floppy Installer repack of FreeDOS 1.3-RC5
Hi all, Pursuant to earlier feedback, three new FDI-x86 repacks are available here: https://drive.google.com/drive/folders/1b7IE-EsK5R1ROmXTaEvYNi9-kfVvH5wi?usp=sharing 1. floppies@2021-12-16/FD13RC5-FloppyEdition+ZIP.zip This build uses ZipSplit instead of Slicer. Output size is similar to slicer-0.17 with the gzip enhancement. Performance is slightly better because decompression does not use temp storage. The payload in each floppy disk is a regular ZIP file that can be opened on a desktop computer. 2. floppies@2021-12-16/FD13RC5-FloppyEdition+TGZ.zip This build is a split tarball. I tried various sort orders, and ran it through zopfli, but this build is only 5% smaller than the ZipSplit or Slicer builds. It uses temp storage equal to the payload size. 3. floppies@2021-12-16/FD13RC5-FloppyEdition+RAR.zip This build uses UnRAR and needs a non-free encoder. The multivolume RAR is half the size of any other archive format, so it is the benchmark for what can be accomplished with 16-bit code on a machine with 1 megabyte of memory. Big savings come from a large dictionary and solid packing, so perhaps 7ZDEC can be enhanced to get a similar result. * Bundled WIL Files The dists have INI files that can be double-clicked to open WinImage, or used to create a SFX media writer for Microsoft Windows. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] floppy installer backup feature broken
The FreeDOS 1.3-RC5 floppy installer always fails if the user chooses a system backup: Creating backup of previous OS files to C:\BACKUP.001. ERROR #1, Subprocess error Failed. CRITICAL error: Unable to backup files in target directory. The installation of FreeDOS 1.3-RC5 has been aborted. Ticketed as: https://github.com/shidel/FDI-x86/issues/2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] slicer-0.17 error code #2
> I went with gzip first because it’s small and 8086 compatible. But now that > it does at least one, it could easily have others added. Like maybe (bz2, > p7zip, etc). It wouldn’t take much to add them. The new gzip feature is likely optimal, especially for 16bit+1meg machines. I've done a few more experiments with repacking the floppy installer and intend to post results later. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] slicer-0.17 error code #2
NB: https://gitlab.com/DOSx86/slicer/-/merge_requests/1 There seems to be a related bug with /e and /i handling, which are no-ops on my test machine. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] slicer-0.17 error code #2
> Please post a bug report at https://gitlab.com/DOSx86/slicer NB: https://gitlab.com/DOSx86/slicer/-/issues/1 >> On DOSBox-X, slicer will fail on random files in a way that looks like a >> race condition. > > Under the same situation? Yes. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] slicer-0.17 error code #2
Hi, In FreeDOS 1.3 RC5, the new slicer handles file overwrites inconsistently in interactive mode. Reproduce the bug by doing this: C:\> SLICER /x /f \SLICES\FREEDOS.SAF /g * /O OUT ... Overwrite BIN\FDINST.EXE, (N)o/(Y)es? N gzip: EGA\BIN\ID583S8Q.GZ: not in gzip format FATAL ERROR: error code #2, unspecified error with "EGA\BIN\ID583S8Q.GZ" Expected behavior is that SLICER skips the current file and finishes the extraction. SLICER behaves as expected on a "Y" input, or in non-interactive mode with the /o switch. The given glob expresses the bug on the first call. If slicer is invoked with a smaller category like "/g Network", then the bug happens on the second call. On FreeDOS 1.3 RC5, slicer will always return error code #2 in the same place. On DOSBox-X, slicer will fail on random files in a way that looks like a race condition. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ISO repack reduces size by 10%
Jerome,
> First, the new versions would need to be checked to ensure compatibility.
> They would probably be fine. But, testing would still need done. I honestly
> just done have the time for that at present.
This work is, in part, the result of doing coverage testing on the distribution.
> But, I think it is to late to consider such a large unplanned change this
> close to the release 1.3-RC5.
Note that this fixes the fails-to-install-all-packages-with-source bug
in the latest release candidate.
> I appreciate the effort you put into creating a PowerShell script to repack
> the repository. However, I do not know if we are going to do that.
This bash script does the same thing. The file is also in the shared
folder in case the listserv mangles it here. I will submit PRs for
additional work now that I know about the Gitlab account.
#!/bin/bash
# fdrepack.sh: FreeDOS repository repacking script.
fdrepack ()
{
TMPDIR=$(mktemp -d)
pushd "$TMPDIR" >/dev/null
unzip -q "$1"
if [[ -d 'SOURCE' ]]
then
pushd 'SOURCE' >/dev/null
for ii in *.7[Zz]
do
if [[ -r "$ii" ]]
then
# Force the source package name to uppercase.
mkdir $(basename "${ii@U}" '.7Z')
pushd $(basename "${ii@U}" '.7Z') >/dev/null
7z x "../$ii"
popd >/dev/null
rm "$ii"
fi
done
for ii in *.[Zz][Ii][Pp]
do
if [[ -r "$ii" ]]
then
# Force the source package name to uppercase.
mkdir $(basename "${ii@U}" '.ZIP')
pushd $(basename "${ii@U}" '.ZIP') >/dev/null
unzip -q "../$ii"
popd >/dev/null
rm "$ii"
fi
done
for ii in *
do
if pushd "$ii" >/dev/null
then
# Unpack and delete old LFN source archives.
find -maxdepth 1 -type f -iname sources.7z -exec 7z x {} \;
-exec rm {} \;
find -maxdepth 1 -type f -iname sources.zip -exec unzip -q {}
\; -exec rm {} \;
# Using the store method here makes upstream sources solid in
the package zip.
zip -0Xoqr "../${ii@U}.ZIP" .
popd >/dev/null
rm -rf "$ii"
fi
done
popd >/dev/null
fi
# Use InfoZIP here for the -k and -o switches.
zip -0Xkoqr "${1}.repack"
advzip -k -p -z -3 -i 15 "${1}.repack"
mv "${1}.repack" "${1}"
popd >/dev/null
rm -rf "$TMPDIR"
}
export -f fdrepack
find ~+ -type f -iname \*.zip -exec bash -c 'fdrepack "{}"' \;
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ISO repack reduces size by 10%
Jerome, > If you can figure out how to get it to work, then it will be worth > considering. It works. Updated builds are posted here: https://drive.google.com/drive/folders/1b7IE-EsK5R1ROmXTaEvYNi9-kfVvH5wi?usp=sharing * The 1.44 MB floppy set is reduced from eight to three diskettes. * The 1.20 MB floppy set is reduced from ten to four diskettes. * The 720 KB floppy set is reduced from fifteen to six diskettes. Creating 360 KB floppies or smaller would require a big extension of the installation program. This update also includes forward error correction for bad media. The nearby BOOT.diff file describes what changed to make the demo happen. > 1) Wether or not it’s License is using an acceptable open source license. > 2) Usage is approved. Not up to me. But if licenses are ok, it should not be > a problem. The encoder is non-free and zero-cost, but the demo otherwise implements all features. > 3) Can be told to create spans of a specific size (so can be used on all > floppy variations, one size fits all). Yes. > 4) Can replace SLICER with little to no overhead added to the installer > and/or RBE (Release Build Environment) > ... > https://github.com/shidel/FDI-x86/tree/master/SETTINGS Thanks for posting this Github link, which I will review later. I looked for a FreeDOS build system earlier but didn't find it. > 5) Can provide the same level of flexibility without the need to manually > modify code when there are package/tag changes. In the updated demo, a @LISTFILE substitutes each possible "SLICER /G %TPU%" invocation. > Can it display general text during the install process? Yes, this can be scripted through the IDOS.SFX module. The given demo displays progress per-file, which is the default. > Does it support NLS and provide text in the users language for prompts? Dunno about NLS, but it can do ANSI.SYS style text in if/then/else blocks. > On systems that support change-line, can it auto-resume without being told to > continue? Dunno what change-line support is... But the extractor won't prompt for a media change if it can already see the next volume, so floppy contents can be copied to a ZipDrive or HDD and the installer will behave properly. > After completion, can it just return an errorlevel to the installer and not > stop with an “I’m done, Press OK” message? The available %ERRORLEVEL% returns are sensible and actionable. > Those and other settings are available in the projects SETTINGS directory. > Specifically, the X86_ALL.LST defines what gets what slicer tags for > assembling the archive. This RAR demo is somewhat an accident and I appreciate how licensing matters. Two alternatives to using RAR or finishing SLICER come to mind now that I better understand the solution: 1a. Replace FREEDOS.SAF with a FREEDOS.TGZ tarball. 1b. Use coreutils to "SPLIT FREEDOS.TGZ" across floppy media. 1c. Unpack it with a "COPY /B PART1+PART2" method and some batch logic. This is how Linux distributions did installation before CD-R media was invented. Zero new compiled code is required to implement it for FreeDOS, and it will cost 10 MB of temporary hard disk space at install time. 2. Use the GPL licensing option in unrarlib to create a RAR2 encoder. Make a "grar" utility like there is "gzip", which would have general application, especially in the retro computing. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ISO repack reduces size by 10%
Jerome,
This PowerShell script generates the optimization that I want as an
end-user on the 'freedos/files/repositories/latest' tree. Only 7Z.exe
is used because 7-Zip 19.00 and AdvZip 2.1 generate outputs that are
nearly identical for a full repack.
# FDREPACK.PS1: FreeDOS repository repacking script.
$ZIPS = Get-ChildItem -Recurse -File -Filter *.ZIP
ForEach ($ZIP in $ZIPS) {
$TMPDIR = Join-Path $ENV:TMP -ChildPath $('FDREPACK_' +
$ZIP.BaseName + '_' + $(New-GUID))
$TMPDIR = New-Item -ItemType Directory -Path $TMPDIR
Push-Location $TMPDIR
7Z x $ZIP.FullName
If (Test-Path -Path 'SOURCE' -PathType Container) {
Push-Location 'SOURCE'
ForEach ($II in @(Get-ChildItem -File -Filter '*.7Z';
Get-ChildItem -File -Filter '*.ZIP')) {
NewItem -ItemType Directory -Path $II.BaseName
Push-Location -Path $II.BaseName
7Z x $II.FullName
Pop-Location
Remove-Item $II.FullName
}
ForEach ($JJ in Get-ChildItem -Directory) {
Push-Location $JJ
If (Test-Path -Path 'SOURCES.7Z' -PathType Leaf) {
7z x 'SOURCES.7Z'
Remove-Item 'SOURCES.7Z'
}
If (Test-Path -Path 'SOURCES.ZIP' -PathType Leaf) {
7z x 'SOURCES.ZIP'
Remove-Item 'SOURCES.ZIP'
}
ATTRIB -A /S
# This makes upstream sources solid in the distro package.
7Z a -tzip -mm=copy -mtc=off -stl $('..\' + $JJ + '.ZIP')
Pop-Location
Remove-Item -Recurse $JJ
}
Pop-Location # SOURCE
}
ATTRIB -A /S
# These are the best zip format 2.0 parameters at the pkzip-2.0 level.
7Z a -tzip -mm=deflate -mfb=258 -mpass=15 -mmt=on -mtc=off -stl
$($ZIP.FullName + '.repack')
Move-Item -Force $($ZIP.FullName + '.repack') ($ZIP.FullName)
Pop-Location # $TMPDIR
Remove-Item -Force -Recurse $TMPDIR
}
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ISO repack reduces size by 10%
Eric, > Please describe that "normalizing" process which makes > the source codes inside the distro packages behave like a > solid archive. Look at a FreeDOS package like 'latest/apps/doszip.zip' and notice the embedded SOURCE/SOURCES.ZIP file. Every package with long file names in upstream source code is like this. Get the optimization by repacking all FreeDOS packages like they use LFN. > Can you provide a list of those damaged ZIP files to us? $ find -type f -iname \*.zip -print0 | xargs -0 -n1 advzip --test --pedantic Failed read end of central directory on freedos/files/devel/asm/nasm/0.98.37/nasm-0.98.37-xdoc.zip Invalid local purpose bit flag 0/2 on freedos/files/devel/asm/octasm/octasm17.zip Unsupported compression method on file RFM.EXE on freedos/files/devel/c/bflat/fbug010.zip Unsupported compression method on file APPINFO/I16BUDOC.LSM on freedos/files/devel/c/gcc-ia16/20200321/i16budoc.zip Unsupported compression method on file APPINFO/I16BUTIL.LSM on freedos/files/devel/c/gcc-ia16/20200321/i16butil.zip Unsupported compression method on file APPINFO/I16ELKLC.LSM on freedos/files/devel/c/gcc-ia16/20200321/i16elklc.zip Unsupported compression method on file APPINFO/I16GCC.LSM on freedos/files/devel/c/gcc-ia16/20200321/i16gcc.zip Unsupported compression method on file APPINFO/I16GCDOC.LSM on freedos/files/devel/c/gcc-ia16/20200321/i16gcdoc.zip Unsupported compression method on file APPINFO/I16NEWLI.LSM on freedos/files/devel/c/gcc-ia16/20200321/i16newli.zip Unsupported compression method on file APPINFO/I16BUDOC.LSM on freedos/files/devel/c/gcc-ia16/20201106/i16budoc.zip Unsupported compression method on file APPINFO/I16BUTIL.LSM on freedos/files/devel/c/gcc-ia16/20201106/i16butil.zip Unsupported compression method on file APPINFO/I16GCC.LSM on freedos/files/devel/c/gcc-ia16/20201106/i16gcc.zip Unsupported compression method on file APPINFO/I16GCDOC.LSM on freedos/files/devel/c/gcc-ia16/20201106/i16gcdoc.zip Unsupported compression method on file APPINFO/I16NEWLI.LSM on freedos/files/devel/c/gcc-ia16/20201106/i16newli.zip Unsupported compression method on file APPINFO/I16BUDOC.LSM on freedos/files/devel/c/gcc-ia16/20210305/i16budoc.zip Unsupported compression method on file APPINFO/I16BUTIL.LSM on freedos/files/devel/c/gcc-ia16/20210305/i16butil.zip Unsupported compression method on file APPINFO/I16GCC.LSM on freedos/files/devel/c/gcc-ia16/20210305/i16gcc.zip Unsupported compression method on file APPINFO/I16GCDOC.LSM on freedos/files/devel/c/gcc-ia16/20210305/i16gcdoc.zip Unsupported compression method on file APPINFO/I16NEWLI.LSM on freedos/files/devel/c/gcc-ia16/20210305/i16newli.zip Unsupported compression method on file APPINFO/I16BUDOC.LSM on freedos/files/devel/c/gcc-ia16/20210418/i16budoc.zip Unsupported compression method on file APPINFO/I16BUTIL.LSM on freedos/files/devel/c/gcc-ia16/20210418/i16butil.zip Unsupported compression method on file APPINFO/I16GCC.LSM on freedos/files/devel/c/gcc-ia16/20210418/i16gcc.zip Unsupported compression method on file APPINFO/I16GCDOC.LSM on freedos/files/devel/c/gcc-ia16/20210418/i16gcdoc.zip Unsupported compression method on file APPINFO/I16NEWLI.LSM on freedos/files/devel/c/gcc-ia16/20210418/i16newli.zip Unsupported compression method on file APPINFO/I16LBI86.LSM on freedos/files/devel/c/gcc-ia16/libi86/20201201/i16lbi86.zip Unsupported compression method on file APPINFO/I16LBI86.LSM on freedos/files/devel/c/gcc-ia16/libi86/20210227/i16lbi86.zip Unsupported compression method on file APPINFO/I16LBI86.LSM on freedos/files/devel/c/gcc-ia16/libi86/20210418/i16lbi86.zip Unsupported compression method on file APPINFO/I16LBI86.LSM on freedos/files/devel/c/gcc-ia16/libi86/20210915/i16lbi86.zip Unsupported compression method on file LIB286/MATH87C.LIB on freedos/files/devel/c/openwatcom/1.5/clib_a16.zip Unsupported compression method on file LIB286/DOS/CLIBC.LIB on freedos/files/devel/c/openwatcom/1.5/clib_d16.zip Unsupported compression method on file LIB286/OS2/CLIBC.LIB on freedos/files/devel/c/openwatcom/1.5/clib_o16.zip Unsupported compression method on file LIB386/OS2/CLBRDLL.LIB on freedos/files/devel/c/openwatcom/1.5/clib_o32.zip Unsupported compression method on file SAMPLES/CLIBEXAM/ABORT.C on freedos/files/devel/c/openwatcom/1.5/clib_samples.zip Unsupported compression method on file LIB286/WIN/CLIBC.LIB on freedos/files/devel/c/openwatcom/1.5/clib_w16.zip Unsupported compression method on file LIB386/NT/CLBRDLL.LIB on freedos/files/devel/c/openwatcom/1.5/clib_w32.zip Unsupported compression method on file LIB286/MATH87L.LIB on freedos/files/devel/c/openwatcom/1.5/cm_clib_a16.zip Unsupported compression method on file LIB386/MATH387R.LIB on freedos/files/devel/c/openwatcom/1.5/cm_clib_a32.zip Unsupported compression method on file LIB286/DOS/BINMODE.OBJ on freedos/files/devel/c/openwatcom/1.5/cm_clib_d16.zip Unsupported compression method on file BINW/WSTUB.EXE on freedos/files/devel/c/openwatcom/1.5/cm_clib_d32.zip Unsupported compression
Re: [Freedos-user] ISO repack reduces size by 10%
Jerome, > I’m not sure what version of UnRAR you are using. I used these two upstream releases to repack the latest FreeDOS 1.3 release candidate: 1. ftp://ftp.rarlab.com/rar/rar250.exe for decompression. FreeDOS ships the 16-bit UnRAR 2.50 binary from this release, and the IDOS.SFX module inside is what provides scripting features. 2. ftp://ftp.rarlab.com/rar/wrar290.exe for compression. The console RAR 2.90 binary from this release has the LFN support needed for FreeDOS source packages. > I’m not sure what you mean by installation scripting. Run rar250.exe for a demonstration. It can make the FreeDOS installer look and behave like the MS-DOS installer. (Screenshot attached.) > Lets take a couple different install situations as examples. > ... > Situation 1, Installation onto basic 286 w/EGA ... > Situation 2, Install for 486 w/VGA ... > Situation 3, Install VirtualBox, (i686 compatible) ... RAR implements the PKZIP listfile syntax, so the SETUP.BAT invocation would change to this; SET TCPU=8086 REM vinfo stuff goes here... unrar x freedos.rar @%TCPU%.txt Where the @LISTFILE corresponds to a SLICER /G %TCPU% build command. Or excluding things that don't run on an 8086 or 80286 processor could be more concise: unrar x freedos.rar -x@%TCPU%.txt > requiring additional overhead for the install program and multiple passes > through the spanned disks. RAR does only one media pass. (This is better than PKZIP, which reads the last floppy disk twice.) > Honestly, I don’t really care about SLICER. Outside of the installer, it has > almost no use and zero chance for any form of adoption by the community. I’d > rather file it in the trash can, use an existing tool and work on other > things. But to my knowledge, nothing else can do what it actually does in an > acceptable manner. The demo that I published can already do it. What are your SLICER /G inputs when building the installation media? -- I will redo the demo to more perfectly replicate current behavior. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ISO repack reduces size by 10%
Eric, I suggest a much shorter algorithm: Simply apply > advzip with the "recompress" option to the ZIP > files :-) If you do this on freedos/files/repositories/latest today, then you'll get: 2,586,758,742 bytes, original total ZIP size 2,535,458,056 bytes, after `advzip -k -p -z -3 ` That's 51 MB, or 2%, for free. But normalizing the source code that is bundled in distro packages is where the big savings happen because it makes the most compressible part of the archive behave like a solid 7Z file. It is interesting that you also got savings with arj and bz2-zip, ARJ has comparable performance, but BZIP2 is too slow to decompress on old computers. The zopfli method will get another few megabytes, but it needs more than a day of CPU time to finish. Of course before this is done on the whole repo, > somebody with PKUNZIP2 has to volunteer to tell > us whether an example advzipped ZIP is still fully > compatible. As far as I remember, this was one of > the design goals of advcomp, so I am optimistic. > The advzip output is indeed compatible with both pkunzip-2.04g and pkunzip-2.50 running on a DOS machine with one megabyte of memory. The way AdvanceCOMP checks and retains metadata is satisfying. If you run advzip on the entire FreeDOS collection, then you'll notice a non-trivial number of malformed and/or corrupt ZIP files. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ISO repack reduces size by 10%
Jerome, Recompression is something that will be considered for the next version of > the repository management utilities. > Your insight is appreciated. I saw the earlier discussion about media size and wanted to point out that there are savings available now at nearly zero cost. SLICER is small. Less than 1/10th the size of RAR. While, this does not > matter as much for a 1.44mb diskette. It matters a lot if a user only has a > 160K drive to work with. With RAR being roughly 353K, that is not going to > happen. > The UnRAR in FreeDOS is 32,086 bytes and already implements all of the things that you want for SCLICER, which is currently 28,188 bytes. (Compression, installation scripting, media spanning, and 160K compatibility.) The corresponding RAR2 codec in unrarlib is GPL'd and approximately 12,000 bytes. I haven't looked at the SLICER source code; this observation is more about how RAR is so good and how easy it was to rebuild the FreeDOS installation media with it. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] ISO repack reduces size by 10%
Hi all, The FreeDOS repo ISO file that was published today can be reduced from 632MB to 579MB by repacking it. This adds 53MB of media headroom, which should reduce pressure to bump packages in future point releases. Original (as of 2021-11-08): https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/cdrom.iso Repack: https://drive.google.com/drive/folders/1b7IE-EsK5R1ROmXTaEvYNi9-kfVvH5wi?usp=sharing The procedure is: 1. Unzip each FDN package. 2. Further unpack each ZIP and 7Z source file. 3. Zip+Store each SOURCES/* tree like it has LFN. 4. Rezip each FDN package like usual. 5. Optimize each package with AdvanceCOMP. The size at each step is: 660,869,928 bytes, original 629,362,932 bytes, rezipped with InfoZip 3.0 605,766,821 bytes, optimized with AdvZip 2.1 Everything stays in zip format 2.0 and remains compatible with PKUnzip 2.04g and FDNPKG. Supposing that other ARCHIVER/* formats were implemented by the FreeDOS packaging system, the cdrom.iso size could be: 627,403,406 bytes, ARJ (-jm) 557,334,645 bytes, ZIP/BZ2 (-9) 495,380,042 bytes, RAR2 (-m5 -mdE -mm) 449,729,467 bytes, 7Z/LZMA2 (-mx9 -ms=on -mqs=on -md=1m) UnRAR 2.50 is particularly impressive because it is 16-bit, fast, and will extract on an 8088 with 640KB of memory. It also has an output size competitive with the kind of 7-Zip 19 archive that can be extracted by 7ZDEC. For fun, I also replaced SLICER with RAR and reduced the number of installation floppies from eight to three. These repacked floppy images are also in the linked folder. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
