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:
*
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
> 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,
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
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.
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
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
> 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
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
> 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.
___
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
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.
>
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
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
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
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
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 `
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
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):
19 matches
Mail list logo
