DOS ain't dead

> I'm not sure from first-hand experience, only crumbs of hints from
> third-party info.
>
> I don't think NTVDM implements 4 GB files for DOS. I think it was only
> FAT32 (as you mentioned, Win95 OSR2 or whatever) exclusively via
> int 21h,
> 716Ch. You might want to ask on news://comp.os.msdos.djgpp since I
> think there was some (??) support in /beta/ 2.04 and newer (e.g. /current/
> 2.05). Actually, I remember that their port (2.04 or newer) of *nix DF.EXE
> would only use FAT32 routines
> (int 21h,
> 7303h ?) if the DOS version reported was 7.

I'm not in NVDM, but regular DOS on bare metal booted off a USB memory stick. Yes, it's the DOS 7.1 IO.SYS / COMMAND.COM which does included FAT32. Same version included with Windows 98 (4.0.2222?). Seems to be hardcoded into the IO.SYS that all fileseeks are signed, even though file *sizes* of between 2 GiB and 4 GiB - 1 are reported correctly in dir listings (ie, aren't negative numbers). I didn't try DOS 6.2, but surely it will suffer from the same problem in seeking, since it officially only supports FAT16. Actually with 64-kb cluster sizes, one can have a FAT16 partition of almost 4 GiB (I think 65524 clusters).

Ironically, in NTVDM, unsigned fileseeks ARE supported. I could run Mik's DOS compiles of Mplayer.exe and seek just fine from 2 GiB to 4 GiB, but in pure DOS these files won't even open ("Can't find file." error). Other DOS programs seem to have no problems seeking in "unsigned" 32-bit mode as well.

>
> So even that I only barely understand, sorry. (There's also "signed int
> bugs" as I think Eric called it in the FreeDOS kernel that keep all files 2
> GB and less. Similarly, DJGPP makes some hardcoded assumptions about 2 GB
> address space, last I heard.
>
> 7-Zip works? Which version and compile? You mean M.K.'s build of 7z.exe
> 16.02 or whatever?

Yes, both Mik's 16.02 build from 2016, and also the 9.20 builds from 2009 create and seek with files from 2 GiB to 4 GiB, although the percentage numbers are messed up (negative percentages!), but large archives of > 2 GiB, are read very well indeed, and extracted to a FAT32 RAMDRIVE. I tested ZIP files up to 4095 MiB and they seek fine. All other 16-bit archivers fail (pkzip, RAR, ACE, ARJ, ESP ...), as well as Xtree Gold, Norton Utilities, etc. Mysteries of the deep... ?

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

The Mplayer DOS port will read large movie files even under real DOS if you store said file on a partition with a file system designed to handle such files and not on a FAT16 partition utilizing some undocumented hack. I store large files on NTFS volumes and MPLayer handles them fine as the IFS driver used to access them actually finds what is supposed to be there.

---
DOS isn't about why. It's about why not.