What are values to enter in fmail for zip compression an decompression
It came only with the arc defined and nothing else

Ruben Figueroa aka Zazz
Mystic Prison Board Sysop
telnet://pbmystic.rdfig.net:24
Web: www.rdfig.net

... As a matter of fact, it IS a banana in my pocket!

--- Mystic BBS v1.12 A49 2023/03/14 (Windows/32)
* Origin: Mystic Prison*Mesquite Tx*pbmystic.rdfig.net:24 (1:124/5014)

Hi Zazz,

On 2023-08-18 17:19:02, you wrote to All:

What are values to enter in fmail for zip compression an decompression
It came only with the arc defined and nothing else

I tested this, and you seem to be right and found a bug... :-( ;-)

These are the default values that are in the source and which are supposed to be set when you run FConfig for the first time without a fmail.cfg file present:

arc32 "PKArc.Com -a"
zip32 "PKZip.Exe -ex"
lzh32 "LHA.Exe a /m /o"
pak32 "Pak.Exe a /ST /P /WN"
zoo32 "Zoo.Exe aP:"
arj32 "ARJ.Exe a -e -u -y"
sqz32 "SQZ.Exe a /p3"
uc232 "UC.Exe a"
rar32 "RAR.Exe a -y -s -m5 -ep -std -cfg-"
jar32 "JAR.Exe a -y"

unArc32 "PKXArc.Com -r"
unZip32 "PKUnzip.Exe -o"
unLzh32 "LHA.Exe e /cm"
unPak32 "PAK.Exe E /WA"
unZoo32 "Zoo.Exe eO"
unArj32 "ARJ.Exe e -c -y"
unSqz32 "SQZ.Exe e /o1"
unUc232 "UC.Exe e"
unRar32 "RAR.Exe e -y -std -cfg-"
unJar32 "JAR.Exe e -y"

But these are the defaults from the DOS era. I currently use the infozip versions, with these command lines:

zip -jq9
unzip -ojq %a -d %f

These work on both Windows and Linux.


Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

Hello, Wilfred van Velzen.
On 19/08/2023 12.21 you wrote:

Hi Zazz,
On 2023-08-18 17:19:02, you wrote to All:

What are values to enter in fmail for zip compression an decompression
It came only with the arc defined and nothing else

I tested this, and you seem to be right and found a bug... :-( ;-)
These are the default values that are in the source and which are supposed to be set when you run FConfig for the first time without a fmail.cfg file present:
arc32 "PKArc.Com -a"
zip32 "PKZip.Exe -ex"
lzh32 "LHA.Exe a /m /o"
pak32 "Pak.Exe a /ST /P /WN"
zoo32 "Zoo.Exe aP:"
arj32 "ARJ.Exe a -e -u -y"
sqz32 "SQZ.Exe a /p3"
uc232 "UC.Exe a"
rar32 "RAR.Exe a -y -s -m5 -ep -std -cfg-"
jar32 "JAR.Exe a -y"
unArc32 "PKXArc.Com -r"
unZip32 "PKUnzip.Exe -o"
unLzh32 "LHA.Exe e /cm"
unPak32 "PAK.Exe E /WA"
unZoo32 "Zoo.Exe eO"
unArj32 "ARJ.Exe e -c -y"
unSqz32 "SQZ.Exe e /o1"
unUc232 "UC.Exe e"
unRar32 "RAR.Exe e -y -std -cfg-"
unJar32 "JAR.Exe e -y"
But these are the defaults from the DOS era. I currently use the infozip versions, with these command lines:

Time to update the defaults for the next release. :)


--
Tommi

---
* Origin: nntp://news.fidonet.fi (2:221/6.0)

Hi Tommi,

On 2023-08-20 12:58:50, you wrote to me:

What are values to enter in fmail for zip compression an
decompression It came only with the arc defined and nothing else

I tested this, and you seem to be right and found a bug... :-( ;-)
These are the default values that are in the source and which are
supposed to be set when you run FConfig for the first time without a
fmail.cfg file present: arc32 "PKArc.Com -a" zip32 "PKZip.Exe -ex"
lzh32 "LHA.Exe a /m /o"
pak32 "Pak.Exe a /ST /P /WN"
zoo32 "Zoo.Exe aP:"
arj32 "ARJ.Exe a -e -u -y"
sqz32 "SQZ.Exe a /p3"
uc232 "UC.Exe a"
rar32 "RAR.Exe a -y -s -m5 -ep -std -cfg-"
jar32 "JAR.Exe a -y"
unArc32 "PKXArc.Com -r"
unZip32 "PKUnzip.Exe -o"
unLzh32 "LHA.Exe e /cm"
unPak32 "PAK.Exe E /WA"
unZoo32 "Zoo.Exe eO"
unArj32 "ARJ.Exe e -c -y"
unSqz32 "SQZ.Exe e /o1"
unUc232 "UC.Exe e"
unRar32 "RAR.Exe e -y -std -cfg-"
unJar32 "JAR.Exe e -y"
But these are the defaults from the DOS era. I currently use the
infozip versions, with these command lines:

Time to update the defaults for the next release. :)

And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar). I wonder if there ever was anyone who used any of those!? ;-)

Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

Hello Wilfred,

On Sunday August 20 2023 13:31, you wrote to Tommi Koivula:

Time to update the defaults for the next release. :)

And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar).
I wonder if there ever was anyone who used any of those!? ;-)

These are the only ones still defined in my congfig (W32)

ZIP PKZip25.Exe -add -nozipextension

ZIP PKzip25.Exe -ext -nozipextension -over

For the vast majority of my links Fmail does no compression. It is left to Binkd. For a few links ZIP is used.

So by all means remove the default for the obscure ones. As long as the user cam still add a seldom used compression method.




Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi Michiel,

On 2023-08-20 14:46:34, you wrote to me:

Time to update the defaults for the next release. :)

And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar).
I wonder if there ever was anyone who used any of those!? ;-)

MvdV> So by all means remove the default for the obscure ones. As long as
MvdV> the user cam still add a seldom used compression method.

I meant remove them completely. If I leave them in, I can just as well keep the defaults...

But on the other hand, why remove them. It doesn't hurt to keep them, although maybe no one uses them.

Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

Hello Wilfred,

On Sunday August 20 2023 15:08, you wrote to me:

And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc,
jar). I wonder if there ever was anyone who used any of those!? ;-)

MvdV>> So by all means remove the default for the obscure ones. As
MvdV>> long as the user cam still add a seldom used compression
MvdV>> method.

I meant remove them completely. If I leave them in, I can just as well keep the defaults...

I was thinking about allowing the user to define his own compression method. A method that is not in the list (yet). There is an option "Custom" but I am unsure how that works. It may be usefull in the unlikely eventy an new compression method pops up that is ideal for use in Fidonet. :)

But on the other hand, why remove them. It doesn't hurt to keep them, although maybe no one uses them.

I am in favour of throwing out no longer used stuff. KISS..


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi Michiel,

On 2023-08-20 16:32:03, you wrote to me:

And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc,
jar). I wonder if there ever was anyone who used any of those!? ;-)

MvdV>>> So by all means remove the default for the obscure ones. As
MvdV>>> long as the user cam still add a seldom used compression
MvdV>>> method.

I meant remove them completely. If I leave them in, I can just as well
keep the defaults...

MvdV> I was thinking about allowing the user to define his own compression
MvdV> method. A method that is not in the list (yet). There is an option "Custom"
MvdV> but I am unsure how that works.

Packing is simple, just use it... For unpacking you need some kind of detection mechanism. Which incase of FMail is left to the "General Unpack Shell". Which is fed everything that is unknown to FMail itself...

MvdV> It may be usefull in the unlikely eventy an
MvdV> new compression method pops up that is ideal for use in Fidonet. :)

But on the other hand, why remove them. It doesn't hurt to keep them,
although maybe no one uses them.

MvdV> I am in favour of throwing out no longer used stuff. KISS..

That was my idea behind it, when I suggested it.


Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

On 20.08.2023 13:31, Wilfred van Velzen wrote:

WV>> But these are the defaults from the DOS era. I currently use the
WV>> infozip versions, with these command lines:

TK> Time to update the defaults for the next release. :)

And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar).

Yep. :)

I wonder if there ever was anyone who used any of those!? ;-)

Back in the day when I had millions of points and downlinks, some liked to use rar and uc. Nowadays it should be enough to support zip. :)

'Tommi

---
* Origin: nntp://news.fidonet.fi (2:221/6.0)

Hi Tommi,

On 2023-08-20 22:14:28, you wrote to me:

WV>> But these are the defaults from the DOS era. I currently use the
WV>> infozip versions, with these command lines:

TK> Time to update the defaults for the next release. :)

And maybe remove the more obscure ones (pak, zoo, arj, sqz, uc, jar).

Yep. :)

I wonder if there ever was anyone who used any of those!? ;-)

Back in the day when I had millions of points and downlinks, some liked to use rar and uc. Nowadays it should be enough to support zip. :)

I'm still using rar on two links. And outside fido rar is very much in use too. And lha is in use in AmigaNet, because it was and still is the default archiver for the Amiga.

Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

Hi All,

On 19 Aug 23 12:21, Wilfred van Velzen wrote to Zazz:
about: "Re: Fmail Compression and Decompression":

What are values to enter in fmail for zip compression an
decompression It came only with the arc defined and nothing else

I tested this, and you seem to be right and found a bug... :-( ;-)

I found and fixed this bug in my development version. And although this is a minor bug, I'll probably make a release, because this is important for new users. This new release might also include new default settings for (un)zip...

Wilfred.

--- FMail-W64 2.2.0.0
* Origin: point@work (2:280/464.112)

Hello Wilfred,

On Sunday August 20 2023 21:54, you wrote to Tommi Koivula:

Back in the day when I had millions of points and downlinks, some
liked to use rar and uc. Nowadays it should be enough to support
zip. :)

I'm still using rar on two links.

Why? They do not support ZIP?

And outside fido rar is very much in use too.

That should be no concern of us. It is (was?) barely used in Fidonet.

And lha is in use in AmigaNet, because it was and still is the default archiver for the Amiga.

How many in Amiganet still actually use an Amiga? Hoe many of those do not also have a Fidonet node and support ZIP? ZIP has become de de facto compression standard in Fidonet.

The problem with keeping all these antiquaria, is that you also have to support it. This will become increasingly difficult when the knowledge evaporates...

KISS...

Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi Wilfred.

19 Aug 23 12:21, you wrote to Zazz:

unzip -ojq %a -d %f

These work on both Windows and Linux.

'-C' might also be a good thing to add.

This is what I have in Husky:

Unpack "unzip -Cjo $a $f -d $p" 0 504b0304

'Tommi

---
* Origin: ---------> (2:221/6.600)

Hi Wilfred.

21 Aug 23 12:13, I wrote to you:

unzip -ojq %a -d %f

These work on both Windows and Linux.

'-C' might also be a good thing to add.

On the other hand, Fmail seems to unpack everything from the arcmail bundle, so it has no effect.

'Tommi

---
* Origin: ---------> (2:221/6.600)

Hi Michiel,

On 2023-08-21 09:57:51, you wrote to me:

Back in the day when I had millions of points and downlinks, some
liked to use rar and uc. Nowadays it should be enough to support
zip. :)

I'm still using rar on two links.

MvdV> Why? They do not support ZIP?

Because I can. ;-)

At the time the choice was made, because rar compressed better. And because it still works there is no reason to change this.

And outside fido rar is very much in use too.

MvdV> That should be no concern of us. It is (was?) barely used in Fidonet.

It means it's a viable choice, where current supported versions are available.

And lha is in use in AmigaNet, because it was and still is the
default archiver for the Amiga.

MvdV> How many in Amiganet still actually use an Amiga?

Enough...

MvdV> Hoe many of those do not also have a Fidonet node and support ZIP?
MvdV> ZIP has become de de facto compression standard in Fidonet.

Not in AmigaNet.

MvdV> The problem with keeping all these antiquaria, is that you also have
MvdV> to support it. This will become increasingly difficult when the
MvdV> knowledge evaporates...

This is true for all of Fidonet technology. Keeping this old techniques working is partly what makes it interesting...


Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

Hi Tommi,

On 21 Aug 23 12:27, Tommi Koivula wrote to Wilfred van Velzen:
about: "Fmail Compression and Decompression":

unzip -ojq %a -d %f

These work on both Windows and Linux.

'-C' might also be a good thing to add.

On the other hand, Fmail seems to unpack everything from the arcmail bundle, so it has no effect.

Indeed -C does nothing incase of FMails unpacking...

Wilfred.

--- FMail-W64 2.2.0.0
* Origin: point@work (2:280/464.112)

Hello Wilfred,

On Sunday August 20 2023 16:50, you wrote to me:

MvdV>> I was thinking about allowing the user to define his own
MvdV>> compression method. A method that is not in the list (yet).
MvdV>> There is an option "Custom" but I am unsure how that works.

Packing is simple, just use it...

Indeed..

For unpacking you need some kind of detection mechanism.

That could be circumveneted by allowing the user to not only specify a compression method for outgoing mail but to als allow the user to specify a decompression method per node. To be used if autodetection fails.

Or let the user specify the "fingerprint" for a custom compression method. From what I remember it is enough to look at the first two bytes of a compressed file. Fingerprint for ZIP is "PK"

OTOH... It may not be worth the effort this late in the game...

Which incase of FMail is left to the "General Unpack Shell". Which is
fed everything that is unknown to FMail itself...

GUS... I never used it myself, never had a need for it. It is still under development or is it abandonware like so many other FTN stuff?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hello Wilfred,

On Monday August 21 2023 10:40, you wrote to me:

I'm still using rar on two links.

MvdV>> Why? They do not support ZIP?

Because I can. ;-)

Bad argument.

At the time the choice was made, because rar compressed better. And because it still works there is no reason to change this.

It is no secret that I am not a member of the "more is better" club. In the POTS age with high cost of data transport "compressed better" was a valid argument. Although even then in the end of the compression evolution the added value was so small that it didn't really matter anymore. Is another one percent of compression efficiency realy worth it.

In the age of FOIP it has become irrelevant. In addition to thet the trend is to not have mailer/tossers just process uncompressed packets and let binkd do any compression.

And lha is in use in AmigaNet, because it was and still is the
default archiver for the Amiga.

MvdV>> How many in Amiganet still actually use an Amiga?

Enough...

Enough to lkep LAH alive?

MvdV>> Hoe many of those do not also have a Fidonet node and support
MvdV>> ZIP? ZIP has become de de facto compression standard in
MvdV>> Fidonet.

MvdV>> The problem with keeping all these antiquaria, is that you also
MvdV>> have to support it. This will become increasingly difficult
MvdV>> when the knowledge evaporates...

This is true for all of Fidonet technology. Keeping this old
techniques working is partly what makes it interesting...

True but at some point one has to make choices that every museum has to make. What do we keep and what do we drop? I see little value in keeping more then one compression method alive for Fidonet. Yes, it is interesting to keep Fidonet alive. But not ALL of the technology that was ever used. Drop some and focus on keeping the rest alive.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi Michiel,

On 2023-08-21 14:30:53, you wrote to me:

For unpacking you need some kind of detection mechanism.

MvdV> That could be circumveneted by allowing the user to not only specify a
MvdV> compression method for outgoing mail but to als allow the user to specify a
MvdV> decompression method per node. To be used if autodetection fails.

I don't think that is a good idea...

MvdV> Or let the user specify the "fingerprint" for a custom compression
MvdV> method. From what I remember it is enough to look at the first two
MvdV> bytes of a compressed file. Fingerprint for ZIP is "PK"

The current detection mechanism in FMail uses up to 7 bytes for the detection, and an offset into the file for some archivers...

MvdV> OTOH... It may not be worth the effort this late in the game...

I don't think so either.

Which incase of FMail is left to the "General Unpack Shell". Which is
fed everything that is unknown to FMail itself...

MvdV> GUS... I never used it myself, never had a need for it. It is still under
MvdV> development or is it abandonware like so many other FTN stuff?

I can't remember using it. I don't think it's still under development. A quick google only gives me this: https://archive.org/details/GUS_170_ZIP so 1993...

Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

Hi Michiel,

On 2023-08-21 14:45:17, you wrote to me:

At the time the choice was made, because rar compressed better. And
because it still works there is no reason to change this.

MvdV> It is no secret that I am not a member of the "more is better" club. In the
MvdV> POTS age with high cost of data transport "compressed better" was a valid
MvdV> argument. Although even then in the end of the compression evolution the
MvdV> added value was so small that it didn't really matter anymore. Is another
MvdV> one percent of compression efficiency realy worth it.

It was way more then 1%...

MvdV>>> How many in Amiganet still actually use an Amiga?

Enough...

MvdV> Enough to lkep LAH alive?

Yes.

MvdV>>> The problem with keeping all these antiquaria, is that you also
MvdV>>> have to support it. This will become increasingly difficult
MvdV>>> when the knowledge evaporates...

This is true for all of Fidonet technology. Keeping this old
techniques working is partly what makes it interesting...

MvdV> True but at some point one has to make choices that every museum has to
MvdV> make. What do we keep and what do we drop? I see little value in keeping
MvdV> more then one compression method alive for Fidonet. Yes, it is interesting
MvdV> to keep Fidonet alive. But not ALL of the technology that was ever used.
MvdV> Drop some and focus on keeping the rest alive.

Well, in this case it doesn't matter what you think. It's what the AmigaNet users want... ;-)

And in a museum available "real" space is probably a lot more expensive then available "virtual" space in AmigaNet, which is kind of limitless...


Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

Monday August 21 2023 16:25, Wilfred van Velzen wrote to Michiel van der Vlist:

Which incase of FMail is left to the "General Unpack Shell". Which is
fed everything that is unknown to FMail itself...

MvdV>> GUS... I never used it myself, never had a need for it. It is still
MvdV>> under development or is it abandonware like so many other FTN stuff?

I can't remember using it. I don't think it's still under development. A quick
google only gives me this: https://archive.org/details/GUS_170_ZIP so 1993...

Got it here in my utils directory! :)

=== Begin OS/2 Clipboard ===
#### # # #### General Unpack Shell | Copyright (C) 1995 and written by
# ## # # #### for DOS | Johan Zwiekhorst
#### #### #### version 1.95 | - ALL RIGHTS RESERVED -
=====================================¤======================================

Syntax: GUS «compressed_filespec» [filespec(s)] [target_path] [switch(es)]

(Entries closed within [] are optional, those within « » are mandatory.)

«compressed_filespec» : := specifies where to find the compressed file
(ARC/ARC+/ARJ/DWC/HA/HAP/HPK/HYP/LZH
/PAK/RAR/SQZ/UC2/ZIP/ZOO & SFXs supported)
[filespec(s)] : := specifies which files should be unpacked
[target_path] : := specifies where to store unpacked files
[switch(es)] : := specifies one or more of the following switches:
/D : Delete archive after successful unpacking
/I : Identify only, don't shell out
/M : unpack Mailarchives (use path for c'file)
/N : do Not use embedded paths while unpacking
/P : Print file(s) on standard output device
/Q : Quiet mode, suppresses shell output
/R : Replace existing files
/S : Scan unpacked files for viruses
/T : Test archive integrity
/V : View archive contents
/Bdir : move Bad archives to specified dir
/Gpswd : supply password for Garbled file
=== End OS/2 Clipboard ===


'Tommi

--- GEcho/2 1.20/Pro
* Origin: * RBB * Lake Ylo * Finland * (2:221/360)

Hi Tommi,

On 2023-08-21 20:13:52, you wrote to me:

MvdV>>> GUS... I never used it myself, never had a need for it. It is
MvdV>>> still under development or is it abandonware like so many other
MvdV>>> FTN stuff?

I can't remember using it. I don't think it's still under development.
A quick google only gives me this:
https://archive.org/details/GUS_170_ZIP so 1993...

Got it here in my utils directory! :)

#### # # #### General Unpack Shell | Copyright (C) 1995
and written by
# ## # # #### for DOS | Johan Zwiekhorst
#### #### #### version 1.95 | - ALL RIGHTS RESERVED -

Found that one too in my archive:

wilnux5:/data/bck/wilnux3/home/wilfred/Documents/arc/COMPRESS # ls -l GUS* -rw-r----- 1 root root 42753 1995-04-15 19:50:00 GUS_150.ZIP

;-)

It's not much newer...


Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

Hello Wilfred,

On Monday August 21 2023 16:33, you wrote to me:

MvdV>> It is no secret that I am not a member of the "more is better"
MvdV>> club. In the POTS age with high cost of data transport
MvdV>> "compressed better" was a valid argument. Although even then in
MvdV>> the end of the compression evolution the added value was so
MvdV>> small that it didn't really matter anymore. Is another one
MvdV>> percent of compression efficiency realy worth it.

It was way more then 1%...

10%? Even if it was 30% it fades away against the increase in speed. I have seen the modems speeds increase from 300 bps to 30000 bps. A HUNDRED fold increase! What is a mere 30% better compression compared to that.

Nowadays with speeds measeured in Mbps or even Gbps isntead of kbps itis completely irrelevant for Fidonet.

MvdV>>>> How many in Amiganet still actually use an Amiga?

Enough...

MvdV>> Enough to leep LAH alive?

Yes.

Hmmm...

MvdV>>>> The problem with keeping all these antiquaria, is that you
MvdV>>>> also have to support it. This will become increasingly
MvdV>>>> difficult when the knowledge evaporates...

This is true for all of Fidonet technology. Keeping this old
techniques working is partly what makes it interesting...

MvdV>> True but at some point one has to make choices that every
MvdV>> museum has to make. What do we keep and what do we drop? I see
MvdV>> little value in keeping more then one compression method alive
MvdV>> for Fidonet. Yes, it is interesting to keep Fidonet alive. But
MvdV>> not ALL of the technology that was ever used. Drop some and
MvdV>> focus on keeping the rest alive.

Well, in this case it doesn't matter what you think. It's what the AmigaNet users want... ;-)

Good point. ;-)

And in a museum available "real" space is probably a lot more
expensive then available "virtual" space in AmigaNet, which is kind of limitless...

The virtual space needed to store the museum pieces may be "limitless", it is certainly not effortless. Once you store a painting in a storage hold, it does not require much attention any more. It can also easely be retrieved in case someone wants to see it. Digital data is different. Without the equipment to read it, it is useless. When storage media become obsolete you have to transfer the data to a new medium. I no longer have the means to read paper tape or punch cards. I could probably make pictures of it and have some smart optical recognition software read it. Floppy disks is more difficult. Compact disk is even more difficult. Long term storage of digital data is not all that easy without constant effort and cost...


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hello Tommi,

On Monday August 21 2023 20:13, you wrote to Wilfred van Velzen:

Got it here in my utils directory! :)

=== Begin OS/2 Clipboard ===
#### # # #### General Unpack Shell | Copyright (C) 1995 and
written by # ## # # #### for DOS | Johan Zwiekhorst #### #### #### version 1.95 | - ALL RIGHTS RESERVED
- =====================================Ï==============================

No OS/2 version?


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

Hi Michiel,

On 2023-08-22 11:08:57, you wrote to me:

It was way more then 1%...

MvdV> 10%? Even if it was 30% it fades away against the increase in speed. I have
MvdV> seen the modems speeds increase from 300 bps to 30000 bps. A HUNDRED fold
MvdV> increase! What is a mere 30% better compression compared to that.

With that that increase in speed also came an increase in content. So better compression still made sense...

MvdV> Nowadays with speeds measeured in Mbps or even Gbps isntead of kbps
MvdV> itis completely irrelevant for Fidonet.

That's true...

And in a museum available "real" space is probably a lot more
expensive then available "virtual" space in AmigaNet, which is kind
of limitless...

MvdV> The virtual space needed to store the museum pieces may be "limitless", it
MvdV> is certainly not effortless. Once you store a painting in a storage hold,
MvdV> it does not require much attention any more. It can also easely be
MvdV> retrieved in case someone wants to see it. Digital data is different.
MvdV> Without the equipment to read it, it is useless. When storage media become
MvdV> obsolete you have to transfer the data to a new medium. I no longer have
MvdV> the means to read paper tape or punch cards. I could probably make pictures
MvdV> of it and have some smart optical recognition software read it. Floppy
MvdV> disks is more difficult. Compact disk is even more difficult. Long term
MvdV> storage of digital data is not all that easy without constant effort and
MvdV> cost...

A few years back I wanted to read some stored CD's serveral years old, and I couldn't. In hindsight, it wasn't that surprising. They were stored in the living room in a rack, where light could get through to them. And they weren't the best quality, certainly not archive quality...


Bye, Wilfred.

--- FMail-lnx64 2.2.0.0
* Origin: FMail development HQ (2:280/464)

On 22.08.2023 12:25, Michiel van der Vlist wrote:

Hello Tommi,

On Monday August 21 2023 20:13, you wrote to Wilfred van Velzen:

TK> Got it here in my utils directory! :)

TK> === Begin OS/2 Clipboard ===
TK> #### # # #### General Unpack Shell | Copyright (C) 1995 and
TK> written by # ## # # #### for DOS | Johan
TK> Zwiekhorst #### #### #### version 1.95 | - ALL RIGHTS
TK> RESERVED
TK> - =====================================¤==============================

No OS/2 version?

Would you need one?

'Tommi

---
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360.0)

Hello Tommi,

On Tuesday August 22 2023 19:40, you wrote to me:

No OS/2 version?

Would you need one?

No, I said goodbye to OS/2 decades ago. But Johan Zwiekhorst was an OS/2 adept, so I would have expected him to compile an OS/2 version.


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.eu (2:280/5555)

On <21 Aug, 08:53>, Wilfred van Velzen wrote to All :

Hi All,

On 19 Aug 23 12:21, Wilfred van Velzen wrote to Zazz:
about: "Re: Fmail Compression and Decompression":

What are values to enter in fmail for zip compression an
decompression It came only with the arc defined and nothing else

I tested this, and you seem to be right and found a bug... :-( ;-)

I found and fixed this bug in my development version. And although this is a minor bug, I'll probably make a release, because this is important for new users. This new release might also include new default settings for (un)zip...

Wilfred.

--- FMail-W64 2.2.0.0
* Origin: point@work (2:280/464.112)

Thanks for the update

- Ruben Figueroa - Prison Board BBS

... A dress makes no sense unless it inspires men to remove it.

--- ProBoard v2.30-A1u4
* Origin: PB Prison BBS (gapbbs.rdfig.net:2828) Mesquite, Tx (1:124/5014.5)