Re: [Freedos-user] ISO repack reduces size by 10%

[Jerome Shidel]

Hi Darik,

I did not read every entry in that list of files. But there were a couple 
things I noticed while skimming it…

Those files are in the mirrors section of the ibiblio server. They don’t really 
have anything directly to do with the packages in the software repo area. Nor 
do they have anything directly to do with the packages on the release media.

Mirror and Repo are just my names for the different areas on the server. They 
don’t have any official names. Anyhow, they are not really related to each 
other.

I have nothing at all to do with the files in the mirrored area. However, I 
believe they are exact copies of the original mirrored files. 

On the other hand, I manage the Repo area and packages. Nowadays, it requires 
little manual intervention on my part and is fully automated. However, I must 
still throw together packages to upload to that section. That is a tedious 
process. 

When putting together those updates, I usually pull them directly from there 
website and not the mirrors area on ibiblio. I have noticed that several 
developers use different programs to generate their zip downloads and while not 
actually corrupt. The compatibility with those files varies among decompression 
software. 

After all the preparations have been done and the files are placed in the 
proper directories for a package, I then use a script to recompress them. That 
script checks for LFN files. If it finds any in the Source directory, it 
compress the whole thing to preserve the LFNs. As for other LFNs elsewhere in 
the package, those individual files are placed in an LFNFILES.zip. 

After the process of preserving LFNs is complete, the entire package is then 
compressed in DOS compatibility mode.

Anyhow, I can’t say wether or not any files in the mirror section are corrupt 
or just incompatible with that zip program. 

But, as I mentioned in an earlier post, I do know there is at least one that 
contains a corrupt archive nested several layers deep inside it’s package. That 
would be the package for OpenGEM. There may be others.

:-)

Jerome




___
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%

[Darik Horn]

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 Shidel]

Hi Eric,

> On Nov 11, 2021, at 4:13 PM, E. Auer  wrote:
> 
> 
> Hi! Please describe that "normalizing" process which makes
> the source codes inside the distro packages behave like a
> solid archive. If you remove them from the ZIP and add a
> TAR of the sources to the ZIP instead, you would get that
> type of result, but it would mean that the install process
> will have to be modified significantly. Also, you would
> need temp storage for the TAR because DOS has fake pipes.
> 
>> 2,586,758,742 bytes, original total ZIP size
>> 2,535,458,056 bytes, after `advzip -k -p -z -3 `
> 
> ...
> 
>> 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.
> 
> ...
> 
>> 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.
> 
> You mean they were already malformed before you recompressed them?
> Can you provide a list of those damaged ZIP files to us?

I think I’ve mentioned that before. Either on the mailing list or during one of 
the online get-togethers.

When the RBE is building metadata about the packages and the release in 
general, it verifies the zip archives. It also, dives through nested zip 
archives. The RBE does throw non-critical error messages/logs about corrupt 
zips. 

There are corrupt zip archives inside some packages. I’m on my phone right now. 
So, I cannot recall which or how many. Next time I do a test build with the RBE 
I’ll let you know.

If I recall correctly, at least one is a couple zips deep in the OpenGEM 
sources.



> 
> Thanks! Regards, Eric
> 
> 
> 
> 
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user



___
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%

[E. Auer]

Hi! Please describe that "normalizing" process which makes
the source codes inside the distro packages behave like a
solid archive. If you remove them from the ZIP and add a
TAR of the sources to the ZIP instead, you would get that
type of result, but it would mean that the install process
will have to be modified significantly. Also, you would
need temp storage for the TAR because DOS has fake pipes.


  2,586,758,742 bytes, original total ZIP size
  2,535,458,056 bytes, after `advzip -k -p -z -3 `


...


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.


...


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.


You mean they were already malformed before you recompressed them?
Can you provide a list of those damaged ZIP files to us?

Thanks! Regards, Eric




___
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 Shidel]

Hi Darik,

> On Nov 11, 2021, at 1:56 PM, Darik Horn  wrote:
> [..]
> 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

Interesting. I assume it is capable of filtering multiple lists. 

>> 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.)

Good. 

>> 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.

If you can figure out how to get it to work, then it will be worth considering. 

It would come down a couple additional things. 

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.
3) Can be told to create spans of a specific size (so can be used on 
all floppy variations, one size fits all). 
4) Can replace SLICER with little to no overhead added to the installer 
and/or RBE (Release Build Environment)
5) Can provide the same level of flexibility without the need to 
manually modify code when there are package/tag changes.

These are of much less important and probable not “deal breakers". But, they 
are things slicer does do and should be known/considered. Can it display 
general text during the install process? For example, while installing from 
slow floppy diskettes, the user is given text regarding the history of FreeDOS 
to read at intervals for something to do while waiting. Does it support NLS and 
provide text in the users language for prompts?  On systems that support 
change-line, can it auto-resume without being told to continue? After 
completion, can it just return an errorlevel to the installer and not stop with 
an “I’m done, Press OK” message? 

> What are your SLICER /G inputs when building the installation media?
> -- I will redo the demo to more perfectly replicate current behavior.

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. The lines label “# tags:” are NOT comments but are directives 
processed by the RBE to build the slicer archive. Oh, and that $PKG_ASSIST$ is 
a macro. The RBE will insert custom user assistance packages (like screen 
readers) at that point when it is being used to create customized versions of 
FreeDOS.

Obviously, the tags are cumulative and some things are just assumed for now. 
But, eventually they can be fine tuned and tags added/removed as needed. 

 https://github.com/shidel/FDI-x86/tree/master/SETTINGS 
 

Jerome

___
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%

[Darik Horn]

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%

[Rugxulo]

Hi,

On Thu, Nov 11, 2021 at 5:05 AM Jerome Shidel  wrote:
>
> On Nov 11, 2021, at 12:12 AM, Darik Horn  wrote:
>
> 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.)
>
>
> I’m not sure what version of UnRAR you are using. But downloading the current 
> version that we have (there maybe and probably is a newer one somewhere)
> from 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/unrar.html
>  , it is 173,588 bytes. It is also listed as "Freeware, see license."

I never really used RAR. The resident expert around here would be
Laaca (Blocek). Although my brother registered WinRAR many years ago,
so I could maybe (barely) ask him for advice. It's a cool archiver,
but I've mostly only used ZIP and 7-Zip in recent years. (Newer
versions of RAR archives [v5?] won't unpack in DOS anymore.)

That old (DJGPP 2.04) build of UnRAR 3.93 was from me, so of course
it's bigger. I think he means even older RAR v2 (1999?), which did
have 16-bit DOS support. Unlike newer versions, that old decompression
code (unrarlib v2) has been GPL'd.

* https://www.sac.sk/download/pack/rar250.exe
* https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/unrar/v2/

AFAIK, last official DOS shareware release of RAR was RARX (EMX,
32-bit) from 2010:

* https://www.sac.sk/download/pack/rarx393.exe


___
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 Shidel]

Hi Travis,

> On Nov 11, 2021, at 10:37 AM, Travis Siegel  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

Re: [Freedos-user] ISO repack reduces size by 10%

[Travis Siegel]

I have never used slicer, so can't comment on it.  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).  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.



On 11/11/2021 6:04 AM, Jerome Shidel wrote:

Hi Darik,


On Nov 11, 2021, at 12:12 AM, Darik Horn  wrote:
[..]

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.)


I’m not sure what version of UnRAR you are using. But downloading the 
current version that we have (there maybe and probably is a newer one 
somewhere) from 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/unrar.html , 
it is 173,588 bytes. It is also listed as "Freeware, see license."


RAR does compression which is very nice. But, isn’t mandatory. It also 
does media spanning that is an absolute must have. I’m not sure what 
you mean by installation scripting. However, SLICER and RAR are very 
different when it comes to intended use. And to my knowledge RAR does 
not do all the things I need/want for the installer.


Lets take a couple different install situations as examples. (I’m 
going to paraphrase the command lines)


Situation 1, Installation onto basic 286 w/EGA

slicer extract 286,EGA programs to C:\

 or
unrar extract 8086\CGA\ directory to C:\
unrar extract 8086\EGA\ directory to C:\
unrar extract 186\CGA\ directory to C:\
unrar extract 186\EGA\ directory to C:\
unrar extract 286\CGA\ directory to C:\
unrar extract 286\EGA\ directory to C:\

Situation 2, Install for 486 w/VGA

slicer extract 486,VGA programs to C:\

 or
unrar extract 8086\CGA\ directory to C:\
unrar extract 8086\EGA\ directory to C:\
unrar extract 8086\VGA\ directory to C:\
unrar extract 186\CGA\ directory to C:\
unrar extract 186\EGA\ directory to C:\
unrar extract 186\VGA\ directory to C:\
unrar extract 286\CGA\ directory to C:\
unrar extract 286\EGA\ directory to C:\
unrar extract 286\VGA\ directory to C:\
unrar extract 386\CGA\ directory to C:\
unrar extract 386\EGA\ directory to C:\
unrar extract 386\VGA\ directory to C:\
unrar extract 486\CGA\ directory to C:\
unrar extract 486\EGA\ directory to C:\
unrar extract 486\VGA\ directory to C:\

Situation 3, Install VirtualBox, (i686 compatible)

slicer extract 686,VGA,VBOX,NETWORK programs to C:\

or

unrar …

Obviously, some of that could be consolidated and streamlined. There 
is a wide range of possible combinations. Hopefully, it demonstrates 
that there are differences between the two programs.


I haven’t really used RAR much in decades and I’m no expert on what 
can and cannot be done with it. Perhaps it could do something similar 
within the limits of a DOS command line without requiring additional 
overhead for the install program and multiple passes through the 
spanned disks.


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.


Eventually, SLICER will get support for compression. That won’t add 
much to the executable. It will not do compression itself but rely on 
other tools to perform those actions. Similar to TAR (which is 
actually a better comparison to SLICER), it will end up with support 
for a variety of external compression algorithms. That would provide 
more flexibility and vastly reduced archive size.


Compression support in SLICER won’t be in RC5. Maybe in 1.3-FINAL. 
But, 

[Freedos-user] Ubuntu updates Samba

[Bryan Kilgallin]

On my legacy FreeDOS PC, at C:, I have just entered "print readme.txt.". 
My Ubuntu tower PC has printed the three pages!

--
members.iinet.net.au/~kilgallin/


___
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 Shidel]

Hi Darik,

> On Nov 11, 2021, at 12:12 AM, Darik Horn  wrote:
> [..]
> 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.)

I’m not sure what version of UnRAR you are using. But downloading the current 
version that we have (there maybe and probably is a newer one somewhere) from 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/unrar.html
 

 , it is 173,588 bytes. It is also listed as "Freeware, see license."

RAR does compression which is very nice. But, isn’t mandatory. It also does 
media spanning that is an absolute must have. I’m not sure what you mean by 
installation scripting. However, SLICER and RAR are very different when it 
comes to intended use. And to my knowledge RAR does not do all the things I 
need/want for the installer.

Lets take a couple different install situations as examples. (I’m going to 
paraphrase the command lines)

Situation 1, Installation onto basic 286 w/EGA

slicer extract 286,EGA programs to C:\

 or
unrar extract 8086\CGA\ directory to C:\ 
unrar extract 8086\EGA\ directory to C:\ 
unrar extract 186\CGA\ directory to C:\ 
unrar extract 186\EGA\ directory to C:\ 
unrar extract 286\CGA\ directory to C:\ 
unrar extract 286\EGA\ directory to C:\ 

Situation 2, Install for 486 w/VGA

slicer extract 486,VGA programs to C:\

 or
unrar extract 8086\CGA\ directory to C:\ 
unrar extract 8086\EGA\ directory to C:\ 
unrar extract 8086\VGA\ directory to C:\ 
unrar extract 186\CGA\ directory to C:\ 
unrar extract 186\EGA\ directory to C:\ 
unrar extract 186\VGA\ directory to C:\ 
unrar extract 286\CGA\ directory to C:\ 
unrar extract 286\EGA\ directory to C:\ 
unrar extract 286\VGA\ directory to C:\ 
unrar extract 386\CGA\ directory to C:\ 
unrar extract 386\EGA\ directory to C:\ 
unrar extract 386\VGA\ directory to C:\ 
unrar extract 486\CGA\ directory to C:\ 
unrar extract 486\EGA\ directory to C:\ 
unrar extract 486\VGA\ directory to C:\ 

Situation 3, Install VirtualBox, (i686 compatible)

slicer extract 686,VGA,VBOX,NETWORK programs to C:\

or

unrar …

Obviously, some of that could be consolidated and streamlined. There is a wide 
range of possible combinations. Hopefully, it demonstrates that there are 
differences between the two programs.  

I haven’t really used RAR much in decades and I’m no expert on what can and 
cannot be done with it. Perhaps it could do something similar within the limits 
of a DOS command line without requiring additional overhead for the install 
program and multiple passes through the spanned disks. 

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. 

Eventually, SLICER will get support for compression. That won’t add much to the 
executable. It will not do compression itself but rely on other tools to 
perform those actions. Similar to TAR (which is actually a better comparison to 
SLICER), it will end up with support for a variety of external compression 
algorithms. That would provide more flexibility and vastly reduced archive 
size. 

Compression support in SLICER won’t be in RC5. Maybe in 1.3-FINAL. But, I would 
count on it. 

> The corresponding RAR2 codec in unrarlib is GPL'd and approximately 12,000 
> bytes.
> 
> I haven't looked at the SLICER source code;

The current version isn’t pretty. It’s mostly a proof-of-concept rough draft. 
It should be rewritten from the ground up. But, I don’t really have the time 
for that either.

> this observation is more about how RAR is so good and how easy it was to 
> rebuild the FreeDOS installation media with it.

I get what your saying and agree that compression would be really really nice. 

:-)

Jerome


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user