Hi,
On Fri, Oct 20, 2017 at 6:48 AM, Joe Forster/STA <s...@c64.rulez.org> wrote:
>
>> How about some of our md5 and sha... sum implementations?
>
> I'm working on pdsum, something that started as an expansion of pdSFV
> but I completely rewrote it since. It compiles with Borland C++ 3.1 to 37
> kbytes (without UPX) but it supports flavors of CRC-16/32/64 as well as
> MD5, SHA1, SHA256, SHA512 (! :-) ), BLAKE2S and BLAKEB. It compiles
> for 8086 or 386; it also compiles with Watcom C, DJGPP, MinGW and
> MinGW64. Would you be interested? I need volunteers for testing...
Fascinating. :-)
Obviously Blair's MD5 tool only supports CRC32, MD5, SHA1. (Well, it
might have buggy support for one or two others, e.g. CRC16.) And most
people these days expect SHA256 or higher (e.g. FreeBSD). I don't
think DJGPP even has sha1sum. And yes, I know that p7zip ("7z h")
supports a lot of these in newer versions, too. Heck, FPC has some
(buggy?) support for CRC32 and MD5.
I don't know what kind of testing you want to do. Just corner cases
like empty files or files (of varying sizes) filled with zeros (or
spaces or ...)? Or do you want to test speed? (Compiler flags are
always a burden to learn and test.)
The main interesting ones (IMHO) for us would be OpenWatcom and DJGPP builds.
>>> * arclds (6 kb)
>>
>> Is that like "file" but only for zip and other archives?
>
> (I'm _very_ proud that it got mentioned at all!) It's not for identifying
> file formats, it rather lists the _contents_ of archives. I've been
> developing it since - but not released it yet -, with the new name
> "arclist", now compiling to 10 kbytes (without UPX) but with support for
> 64-bit file sizes (ZIP64). And a 8086 version and a multi-platform C
> version, too.
Yes, you told us once about the rewrite, but I never bugged you about
it. Heck, I've been using this tool for years. (Back before my MetaDOS
had Unzip, I included it just so you could at least view some
archives. It's still included, even though I "mostly" only list .ZIPs.
Like mentioned already, I miss .gz [GZip] support, which is honestly
fairly easy to add, but I'm too lazy to do it myself.)
> At this very moment, I'm hacking TASM-style features into NASM so that I can
> compile arclist with NASM instead of TASM.
I have already rebuilt ARCLDS (with small patch) using JWasm. I
halfway wanted to convert it to NASM but got too busy. (I did already
convert CRC32 to NASM, which was easy.) IIRC, the main feature you
missed in TASM was "union" (which MASMv6 and JWasm support, I
think??). But NASM has somewhat wimpy (or almost non-existent) support
for structs and unions. Same with FASM (except "maybe" with Win32
macros). I'm sure it can be kludged / worked around but only
tediously. These days, I'd recommend FPC (i8086-msdos) instead, if
starting from scratch. But there's still lots of old legacy TASM code
out there.
> I would be honored to donate both to FreeDOS, with public domain license.
I'll mirror anything that's free/libre to iBiblio.org for you/us, if you want.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
