DOS ain't dead

SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? (Users)

posted by Zyzzle, 20.10.2021, 14:51

> > Quick question about SEEKEXT: I installed the TSR, (I'm using the Win95
> > OSR2 "MS-DOS" v. 7.1) thinking it would make existing DOS programs using
> > signed longint filesizes into unsigned longint seeks. As in, it would
> > enable DOS programs to see "negative" file sizes from 2 GiB to 4 GiB-1
> as
> > valid sizes. It did not. With the TSR installed, all programs behaved as
> > before. With files > 2 GiB programs report strange error messages (file
> > cannot be opened, or can't seek in file, etc) and do not work with these
> > large files.
> >
> > Do all the programs need to be recompiled (unlikely or impossible, as
> > source isn't available) in order to work with SEEKEXT to enable longint
> > unsigned seeks? Archivers like pkzip, RAR, or ACE only support creation
> of
> > 2 GB archives in "pure" DOS.
>
> SEEKEXT doesn't do anything for the programs that need signed 32-bit
> seeking. Plus, it doesn't do anything at all for non-redirected (local FAT
> FS) file systems on MS-DOS 7.10 (or any MS-DOS version).
>
> The short seek (int 21.42) hook of SEEKEXT is only for handling
> 32-bit seeks using a 64-bit (long seek) interface. If your file system does
> not support the long seek int 21.7142 interface then SEEKEXT's short seek
> hook will pass all 21.42 calls to DOS unmodified. It is merely a
> convenience to sign-extend SEEK_CUR and SEEK_EOF seek offsets from a 32-bit
> value (interpreted as signed) to 64-bit, and zero-extend SEEK_SET seek
> offsets to 64-bit. (And it returns either a 32-bit value representing -4
> GiB..+4 GiB or else FFFF_FFFFh as the resulting position.) This is only
> useful for programs which do not use absolute offsets and which operate on
> files with the 21.7142 long seek interface supported.
>
> (The other hook of SEEKEXT is to redirect 21.7142 to 2F.1142, which is a
> special long seek redirector interface defined for dosemu2. To my awareness
> dosemu2 MFS-redirected file systems have the only implementation of this
> function.)
>

Now I understand much better, and thanks very kindly for explaning this. I suspected Longseek meant 64-bit fileseeks and not "long" integer (ie, 32-bit integers). So, I understand the stated purpose of SEEKEXT was outside the scope of "signed" or "unsigned" 32-bit seeks at all, and was made to work exclusively within the realm of 64-bit seeks.



> > Believe we had a discussion almost a decade ago on longseek and unsigned
> > 32-bit and 64-bit file sizes in DOS. I know implementing 64-bit sized
> seeks
> > would be much more involved than enabling unsigned (4 GiB-1) 32-bit
> > fileseeks.
> >
> > Is it a DOS limitation, or a program limitation? The only program I've
> > found which "seems" to creat filesizes > 2 GiB is the DOS compilation of
> > 7zip. It creates such files, reads them, but is the only such DOS
> program
> > I've found that will. It uses CWSDPMI as the extender.
> >
> > The Mplayer DOS port will not read large movie files from between 2 GiB
> and
> > 4 GiB, failing to open them. Again, in "ms-dos" 7.1
>
> Two possibilities there: The application may incorrectly check for negative
> seek results rather than only -1 (in 32 bit = FFFF_FFFFh) for errors. And
> as Rugxulo mentioned, a special flag may be required by MS-DOS 7.10 (though
> it seems to be valid for SFN 21.6C too, not only the LFN Extended
> Open/Create):
> BH = flags, bit
> 4 = (FAT32) extended size (allow 4GB files instead of 2GB).

I was dealing specifically with SFNs, but did of course have the FAT32 version of DOS (ie, the "unofficial v. 7.1" released with Win 95 OSr2 and Win 98). Didn't have any LFN support loaded, however. And, I suspect, as you said, the 16-bit DOS programs simply don't know how to deal with "negative" file sizes, bombing out on any seek activity, once they see a "negative" filesize (> 2 GiB) as an overflow error.

If there is a special flag, I'm unsure how to enable it or if it indeed needs to be enabled at compilation and therefore programs need to be recompiled in order to enable the flag at runtime.

I thought R. Loew had somehow overcome this problem, but it seems not generally via an IO.SYS patch. His FAT32+ utilities and patches seem to correctly support unsigned access (correctly only identifying a -1 value (0xFFFFFFFF), and thus utilizing the full FAT32 capability, and also enabling files of > 4 GiB by means of splitting the files into 4 GiB - 1 sized chunks. However, I believe these "unsigned" fileseeks are only supported via his own utility, and NOT in the general sense of all int 21 calls.

Complete thread:

• SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? - Zyzzle, 20.10.2021, 05:00 (Users)
  • SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? - Rugxulo, 20.10.2021, 11:10
    • SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? - Zyzzle, 20.10.2021, 14:37
      • SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? - KormaX, 25.11.2021, 17:42
  • SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? - ecm, 20.10.2021, 12:50
    • SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? - Zyzzle, 20.10.2021, 14:51
      • SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? - Oso2k, 22.10.2021, 00:39
        • SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? - Zyzzle, 22.10.2021, 02:45
    • SEEKEXT and enabling unsigned 32-bit DOS int 0x21 fileseeks? - KormaX, 26.11.2021, 10:31