DOS ain't dead

Hi,
one more pebdac question:
Is it possible that the archiver zoo supports only FAT16 when extracting files?

Reason:
On FAT32 I get an error message:

ZOO: FATAL: I/O error or disk full.

I do not get this message on a FAT16 machine.
When I compress on FAT32 there seem to be no problems.

Thanks for response.

Fritz

Strange, a packer shouldn't use direct IO but DOS services. What packer you exactly have? I found in my collection this one, can try later...
zoo 2.1 $Date: 91/07/09 02:10:34 $

---
DOS gives me freedom to unlimited HW access.

> Strange, a packer shouldn't use direct IO but DOS services.

Yes, but it might check the available disk space before unpacking a file and expect a value below 2GB or overflow otherwise. You should either free up or allocate a few hundred MBs on the file system; I would expect this to make it work again...

> it might check the available disk space before unpacking a file
> and expect a value below 2GB or overflow otherwise.

Good thought! However, according to RBIL, the FAT12/FAT16 function int 21h with ah=36h should report "2 GB - 32 KB" if more space than that is available, exactly to avoid this kind of problem with programs which might interpret values between 2 GB and 4 GB as negative signed integers.

The FAT32 call is int 21h with ax=7303h, by the way, "get extended free space on drive". Interestingly, Win9x even clips the reported number of free FAT32 clusters to 64k if DOS TSR are active, effectively also limiting reported free space to 2 GB, according to RBIL.

Apps which work on really old DOS versions could also use int 21h, function ah=1bh or 1ch, but those should only report disk, sector and cluster size, not free space on disk. RBIL says those functions report wrong values in Win9x.

---
FreeDOS / DOSEMU2 / ...

Seems to work fine for me (same version RayeR reported), using MSDOS Player in Win10 (400GB free) and FreeDOS in the root of a FAT32 drive (576MB free).

Hi! Turns out that zooext.c, msdos.c and dosfns.h work with a signed 16-bit cluster size. This overflows when clusters are 32 kB or larger, making ZOO believe that your disk is full :-p

Question: Are you aware of any OTHER apps with the same bug? After all, HIMEM even has a command line option to limit reported XMS to less than 32 MB because multiple apps have a similar overflow in their XMS handling :-p

---
FreeDOS / DOSEMU2 / ...

> Hi! Turns out that zooext.c, msdos.c and dosfns.h work with a signed 16-bit
> cluster size. This overflows when clusters are 32 kB or larger, making ZOO
> believe that your disk is full :-p
>
> Question: Are you aware of any OTHER apps with the same bug? After all,
> HIMEM even has a command line option to limit reported XMS to less than 32
> MB because multiple apps have a similar overflow in their XMS handling :-p

Thanks for response. The last version of the program is from 1991, I assume that there will be no updates in the near future, so I will add a comment in FD help that it may cause problems on newer systems.

At the moment I do not remember OTHER apps with the same bug, but there are still a lot of programs that support FAT16 only and should be improved for FAT32 usage, e.g. chkdsk and scandisk (scandisk has only restricted FAT32 support).

> Thanks for response. The last version of the program is from 1991, I assume
> that there will be no updates in the near future, so I will add a comment
> in FD help that it may cause problems on newer systems.

A lot of archivers reused the same compression code (with small tweaks), e.g. ARC, LZH, ZOO, ARJ, ZIP, RAR. They were all competing and thus redundant, so I don't expect most people to actively use all of them.

BOOZ was a .ZOO unpacker only. FIZ (?) .ZOO sfx is hard to find. X1 DOS archiver (e.g. on Sac.SK) supported multiple archives including .ZOO (but needed to be restubbed since its older PMODE/W was buggy). There was also a third-party source that supported DJGPP v1 (!). I can't quite remember and would have to search old emails or forum posts, but I think it was UnZOO. I vaguely remember a Cygwin build.

> At the moment I do not remember OTHER apps with the same bug, but there are
> still a lot of programs that support FAT16 only and should be improved for
> FAT32 usage, e.g. chkdsk and scandisk (scandisk has only restricted FAT32
> support).

For FAT32, I think dosfsck is preferred.

> Thanks for response. The last version of the program is from 1991, I assume
> that there will be no updates in the near future, so I will add a comment
> in FD help that it may cause problems on newer systems.

I am more optimistic here: The program is open source and there will be FreeDOS fans who still have the compilers used for ZOO long ago. Those could help us out to create a fixed binary.

A fix for the source code is not hard to write, just changing the data type for all occurances of the cluster size should be enough. So the main bottleneck from my point of view is finding somebody willing to compile the fixed sources after that.

Regarding CHKDSK and SCANDISK: The reason why there is a FreeDOS port of DOSFSCK instead of a FAT32 modification of CHKDSK is that FAT32 has a lot more metadata. Each File Allocation Table can be multiple megabytes. So for me, it made more sense to port a 32-bit CHKDSK equivalent tool than to try to teach a 16-bit FAT16 actual CHKDSK how to deal with so much data. Of course, it would be nice to have a variant of DOSFSCK which looks and feels a bit more like CHKDSK, but I would not try to make a 16-bit FAT32 checker, that would have really bad performance. SCANDISK basically is eye-candy for CHKDSK, so it has rather low priority to have for me personally?

---
FreeDOS / DOSEMU2 / ...

Ah, stupid bug, why a lot of people use signed data types where are no negative values used... What source files did you analyzed? The original zoopacker that version I reported or something newer? Can you give a link? If it's for Borland C I still have the compiler installed... I also have some 2GB FAT16 partitions wit 32k clusters...

---
DOS gives me freedom to unlimited HW access.

* Cygwin's patched ZOO 2.10-1 sources
* EDIT: actual source download link here

* booz20.zip

* x1dos95a.zip
* x1nt95a.zip

* unzoo.c (improved from BOOZ)

> I am more optimistic here: The program is open source and there will be
> FreeDOS fans who still have the compilers used for ZOO long ago. Those
> could help us out to create a fixed binary.
>
> A fix for the source code is not hard to write, just changing the data type
> for all occurances of the cluster size should be enough. So the main
> bottleneck from my point of view is finding somebody willing to compile the
> fixed sources after that.

Thanks for reminding me what a horrible development environment DOS was!

The patch:

--- a/msdos.c
+++ b/msdos.c
@@ -69,7 +69,7 @@
 
 unsigned long space (drive, alloc_size)
 int drive;
-int *alloc_size;
+unsigned long *alloc_size;
 {
        unsigned long free_space;
        union REGS regs;
@@ -85,7 +85,7 @@
        /* ax=0xFFFF on error */
 
        /* cluster size = sectors/cluster * bytes/sector */
-       *alloc_size = regs.x.ax * regs.x.cx;
+       *alloc_size = (unsigned long) regs.x.ax * regs.x.cx;
 
        /* space = cluster * alloc_size */
        if (regs.x.ax == 0xffff)
--- a/zooext.c
+++ b/zooext.c
@@ -85,7 +85,7 @@
 int null_device = 0;                      /* are we sending to null device? */
 #ifndef PORTABLE
 int fast_ext = 0;                         /* fast extract as *.?Z? */
-int alloc_size;                           /* disk allocation unit size */
+unsigned long alloc_size;                 /* disk allocation unit size */
 #endif
 struct direntry direntry;                 /* directory entry */
 int first_dir = 1;                                                             /* first dir entry seen? */
--- a/zoofns.h
+++ b/zoofns.h
@@ -80,7 +80,7 @@
 void zooexit PARMS ((int));
 long inlist PARMS ((char *, unsigned int *, unsigned int *, unsigned *,
                                        unsigned *, unsigned *, long *, int));
-unsigned long space PARMS ((int, int *));
+unsigned long space PARMS ((int, unsigned long *));
 void addbfcrc PARMS ((char *, int));
 void addfname PARMS ((char *, long, unsigned int, unsigned int,
                                                        unsigned, unsigned));


The binary: 7z

> If it's for Borland C I still have the compiler installed...

It's Turbo C++, available at winworld. It might also build with later versions of Borland C++, but I did not test this.

I ran a first "quick and dirty" test; it worked. Give me some time to test the whole program.
Would it be possible to send a file packet with source code and bin to Jerome Shidel when it is completely tested so that he can use it for FDT240x ?

Thx

Fritz

PS: If each bug would be fixed so fast in FD it would make much more fun to write the help. And I know a lot of bugs...

> Thanks for reminding me what a horrible development environment DOS was!
>

UnZOO is a modified BOOZ unpacker that fixed a lot of portability issues and added some features, I think. It claims to have (also) compiled with DJGPP (v1). However, for better FAT32 support, you'd probably want DJDEV 2.04 or newer (like 2015's 2.05).

Outside of a rare need to run a 16-bit version atop FAT32, I don't see the point of using Borland tools here. (Besides, why not OpenWatcom?)

> Thanks for reminding me what a horrible development environment DOS was!
>

You was faster :)
I tried it recompile too and I have to note some obstacles I needed to overcome...
* The make file was not compatible with borland make, I have to find and DL NDMAKE
* makefile needed some abs.path editing
* link was not found, not sure what they used but I decided to use borland tlink
* linking faile because of too long command line (many obj files). I had to create response file and call tlink with it.
Then it finally rebuilt and it works on my 2GB FAT16 partitions. I used BC 4.52.

---
DOS gives me freedom to unlimited HW access.

> I tried it recompile too and I have to note some obstacles I needed to
> overcome...
> * The make file was not compatible with borland make, I have to find and DL
> NDMAKE
> * makefile needed some abs.path editing
> * link was not found, not sure what they used but I decided to use borland
> tlink
> * linking faile because of too long command line (many obj files). I had to
> create response file and call tlink with it.
> Then it finally rebuilt and it works on my 2GB FAT16 partitions. I used BC
> 4.52.

File zoo.1 reads:

The executable version 2.0 for MS-DOS is currently compiled with Borland's Turbo C++ 1.0.

But wcomp -3 -v says:

ZOO.EXE       Microsoft C 6.0           [Overlays] [OS/2]
              [ Author : Rahul Dhesi -- ]
              [Stack overflow checked]

---
Forum admin

> > Thanks for response. The last version of the program is from 1991, I
> assume
> > that there will be no updates in the near future, so I will add a
> comment
> > in FD help that it may cause problems on newer systems.
>
> I am more optimistic here: The program is open source and there will be
> FreeDOS fans who still have the compilers used for ZOO long ago. Those
> could help us out to create a fixed binary.

Yes, Zoo source code is available, but it you will also find: Noncommercial use permitted

Only bilf.c reads:

This program is:
   (C) Copyright 1987 Rahul Dhesi.
   All Rights Reserved.

Permission is hereby granted to copy and modify this for any purpose,
whether commercial or noncommercial, provided only that the above
copyright notice and this paragraph be preserved and included
in all copies.

(No, I'm not a license purist.)

---
Forum admin

> * link was not found, not sure what they used but I decided to use borland
> tlink
> * linking faile because of too long command line (many obj files). I had to
> create response file and call tlink with it.

I also fought this. Apparently there is some special treatment in ndmake for the command "link". It will handle the response file automatically in this case. So the only thing that you need to do to overcome this issue is rename "tlink.exe" to "link.exe".

> > > Thanks for response. The last version of the program is from 1991, I
> > assume
> > > that there will be no updates in the near future, so I will add a
> > comment
> > > in FD help that it may cause problems on newer systems.
> >
> > I am more optimistic here: The program is open source and there will be
> > FreeDOS fans who still have the compilers used for ZOO long ago. Those
> > could help us out to create a fixed binary.
>
> Yes, Zoo source code is available, but it you will also find:
> Noncommercial use permitted
>
> Only bilf.c reads:
>
> This program is:
> (C) Copyright 1987 Rahul Dhesi.
> All Rights Reserved.
>
> Permission is hereby granted to copy and modify this for any purpose,
> whether commercial or noncommercial, provided only that the above
> copyright notice and this paragraph be preserved and included
> in all copies.
>
> (No, I'm not a license purist.)

according to https://github.com/troglobit/zoo/commit/42f8d94ad942df4d45758fc999204427a8471e07 , it goes public domain now.
but in this repo there is no more Turbo C++ makefile,
I asked but author has no intention for this. he said people can fork it and bring it back.

> So the only thing that you need to do to overcome this issue is
> rename "tlink.exe" to "link.exe".

It didn't work for me for some reason so I had to created response file manually and create link.bat
tlink @link.cfg

link.cfg:
/c /m /s E:\BC31\LIB\c0c.obj addbftcc.obj addfname.obj basename.obj comment.obj crcdefs.obj getfile.obj lzc.obj lzd.obj machine.obj makelist.obj misc.obj misc2.obj nextfile.obj needed.obj options.obj parse.obj portable.obj prterror.obj version.obj zoo.obj zooadd.obj zooadd2.obj zoodel.obj zooext.obj zoofilt.obj zoolist.obj zoopack.obj io.obj lzh.obj maketbl.obj maketree.obj huf.obj encode.obj decode.obj msdos.obj,zoo.exe,zoo.map,E:\BC31\LIB\cc.lib

---
DOS gives me freedom to unlimited HW access.

I ran some more tests with the file above. It worked fine - even with a 1 GB big file.
So - whoever finishes it - could you forward the bugfixed package to FD?
Thanks.

> > Yes, Zoo source code is available, but it you will also find:
> > Noncommercial use permitted
> >
> > Only bilf.c reads:
> >
> > This program is:
> >    (C) Copyright 1987 Rahul Dhesi.
> >    All Rights Reserved.
> >
> > Permission is hereby granted to copy and modify this for any purpose,
> > whether commercial or noncommercial, provided only that the above
> > copyright notice and this paragraph be preserved and included
> > in all copies.
> >
> > (No, I'm not a license purist.)
>
> according to
> https://github.com/troglobit/zoo/commit/42f8d94ad942df4d45758fc999204427a8471e07
> , it goes public domain now.

Thanks for bringing this to my attention!

Excerpt from public-domain.eml:

Return-Path: <dhesi@rahul.net>
Date: Sat, 19 Jun 2004 13:50:26 -0700 (PDT)
From: dhesi@rahul.net
To: Niklas Vainio <nvainio@iki.fi>
Subject: Re: License of Zoo

Hi, the last release of the zoo archive program was marked entirely
public domain, with no restrictions. I'm sure this statement will be
found somewhere in the files in the sources. If not, I hope this email
will suffice:  everything in the zoo package is entirely public domain,
with no restrictions whatsoever.

Rahul

---
Forum admin

unzoo.c is a single file (no makefile needed) and public domain (derived from booz). But it doesn't handle the older style of compression, only the newer LZW method from 2.10. However, it does handle subdirs and a few other features, unlike booz.

Remember that you probably only need extraction, not archive creation, so you don't need zoo proper, only an unpacker.

Yes, ZOO 2.10 was relicensed (why else would Cygwin include it?), but 2.01 also had a better license IIRC (probably also public domain). Like I said, a lot of these old archivers were based upon Haruhiko Okumara's AR.

A simple workaround for the cluster problem would be to temporarily create a small FAT16 RAM drive to unpack on.