> 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
Hi,
> On Dec 16, 2021, at 1:49 PM, Darik Horn wrote:
>
> 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.
Could be.
Originally, those switches we designed for mostly creating an
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
> On Dec 15, 2021, at 7:05 PM, Darik Horn wrote:
>
>> 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
> 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 Darik
> On Dec 15, 2021, at 5:11 PM, Darik Horn wrote:
>
> 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
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
