DOS ain't dead

> There was an idea to update RBIL that seems to be most complete DOS/INT
> description. It's not clear if it is still maintainded by someone. There's
> also FreeDOS wiki http://wiki.freedos.org but that seems rather documents
> commands not API.

RBIL is an excellent resource, and should be updated.

However, I am thinking of full, detailed documents, such as the DPMI and XMS specs. Ideally, they should be authoritative, and comprehensive enough to answer reasonable questions arising in the development of implementations. This is beyond the scope of RBIL.

-Albert.

>
> <smartass mode>
>
> 1) install the 64bit Linux distro of your choosing
> 2) boot into single user mode
>
> viola !!!
>
> 64bit DOS with all of the features you mention and many, many more !
>
> </smartass mode>
>
>

I already did that. I ditched Windows 7 in favour of Linux Mint in early December 2019. I've kept my Win7 install, but rarely have to boot it, and I prefer to do that in VMware anyway. The main thing I need it for is iTunes to manage my music library and iPod.

I recommend others to do the same. I have no regrets, but on the contrary, I think I should have done it right away when I bought the computer. My current session has been up for more than a quarter (of a year), and it is faster than Windows.

-Albert.

...
> > 1. large physical memory support (ie. above 4 GB)
> > 2. standardised 64-bit program support
> > 3. MBR amendments to support blocks (sectors) above 4G
> > 4. large file support (llseek, etc.)
> > 5. Memory mapped file API for INT21.
> > 6. SMP (multiprocessing) support
...
>
> They're all good and would be useful. #2 and #6 have been demonstrated by
> NDN and other attempts.

I briefly looked into NDN (Necromancer's DOS Navigator), and I saw mentions of "DPMI64", but I was unable to find any such document.

> Most important seem to be 2 and 3, along with perhaps native ExFAT (FAT64)
> support. Large media support and large file sizes. #1 is being worked on as
> we speak -- HIMEMSX has shown large memory support is possible. At very
> minimum get rid of signed filesizes, extend lseek to be at least an
> unsigned 32-bit integer.

Support for exFAT would be useful. However, there are two other alternatives, which, as matter of fact, can be complementary to exFAT:
(1) de novo DOS-friendly file system formats
(2) a convention like the Linux UMSDOS for supporting extended features atop a legacy FAT (and/or VFAT or FAT32) file system.

By DOS-friendly, I mean readily capable of being implemented in real mode.

Another example of implementing features on top of legacy FAT, is the DJGPP convention for symbolic links.

-Albert.

> Another topic for documentatition is the other stuff from Japheth's forge -
> the interface for JLM pluggins with his JEMM386 (they have .DLL extension)
> (however on the user level is sufficient to know the syntax
> DEVICE=JLOAD.EXE SOMETHNG.DLL)

That is interesting, because I am in a very preliminary phase of implementing a DOS multitasker inspired by the Win3/9x VMM+VxD layer. VMM is the kernel mode component of Windows 386 Enhanced mode, and incidentally implements DPMI (KRNL386 is in fact a DPMI application!), and VxDs (Virtual x Device; often with a *.386 extension) are loadable kernel modules. That sounds very analogous to JLMs.

It is feasible, though scarcely easy, to build an environment allowing the use of pre-existent drivers/modules from other systems. The "WDM" driver format used in Windows 98/Me proves that it is possible to support NT-style drivers. In the Linux world, there is "NDISWrapper", which allows Windows NDIS network drivers to be used for Linux. Soberly, that is more useful than supporting VxDs, although I much prefer the latter.

As deduced from beta releases of Chicago (Win95+DOS7), Microsoft was going to implement a "DOS=Enhanced" setting in CONFIG.SYS. This would cause DOS to load the VMM+VxD-layer. In this beta release the latter was contained in the file "DOS386.EXE" (which was WIN386.EXE in Win3.x, and VMM32.VXD in the commercial release of Win95). MS thought better of it -- probably due to DOS-negativity in the computer trade press.

I am rambling here, but maybe JEMM386 could be turned into a DOS386.EXE and FreeDOS could implement a "DOS=Enhanced" feature? DOS386 could load 32-bit kernel modules specified in a SYSTEM.INI file. These modules could implement hardware drivers, disk caches, etc. Then, maybe a basic KRNL386.EXE DPMI GUI application could be made to run on top of it? KRNL386 could in turn load a KERNEL32.DLL, which might perhaps be based on the pre-existent WINE implementation of the Win32 API. Alternatively, the system could make use of DLLs from modern Windows, because these are ubiquitous even though not freely available. In fact, the HX DOS extender already supports the use of Windows DLLs.

-Albert.

> Other interresting field is the proposed standard DMMI (DOS multicore mode
> interface) which can be seen here:
> https://www.codeproject.com/Articles/894522/The-Low-Level-M3ss-DOS-Multicore-Mode-Interface

Does it work on a real PC for someone else?
I my case when I run entry.exe from bare DOS (RM) it just displays
Long Mode [VM]
and reboots immediatelly :\

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

> Hello Albert,
>
> > 5. Memory mapped file API for INT21.
>
> Not sure how useful this would be in the context of MS-DOS in general.
> Things like memory-mapped file I/O and demand loading are very much tied to
> virtual memory paging mechanisms, and MS-DOS is meant to support systems
> which do not even have any notion of virtual memory.
>
> An API for memory-mapped files might kind of make sense in the context of
> 32-bit DPMI, though.

The latter is what I had in mind. As we all know, there is a shortage of address space in real/V86 mode, and even in 16-bit protected mode, there is a 64KB segment size barrier, which would serve to make memory mapped files even more cumbersome to use than regular file I/O.

> Thank you!

Not sure what you're thanking me for, but you're welcome :)

-Albert.

> An API for memory-mapped files might kind of make sense in the context of
> 32-bit DPMI, though.

I think so. DPMI already had API function to map MMIO for its client. I have no idea what relamode DOS would do with it, it's used by pmode apps.

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

> > 3. MBR amendments to support blocks (sectors) above 4G
>
> GPT is right there. I don't think extending the MBR scheme is going to be
> supported by many implementations.

GPT is baroque -- even its name points this out ("GUID" partition table).

What I had in mind would be almost trivial to implement, and with open source systems, I might even be able to do it myself.

I have two schemes in mind:

(a) add a new signature and/or checksum to the existing MBR format. Perhaps the CHS fields could be used to store the extended LBA fields. Alternatively, some additional space could be reserved.

(b) again, add a signature and/or checksum. Simply use additional sectors/blocks for the extensions. Even with existing disks, there is usually plenty of space before the start of the first partition.

> (For a hack, we could try to support "33 bit LBA" schemes, ie the 32-bit
> fields for start and length are kept, but it is valid for start and length
> to *both* be up to FFFF_FFFFh, so (with 512 B/s) a 2 TiB - 512 B FAT32
> partition may start at sector FFFF_FFFFh. That is, allowing to use nearly 4
> TiB of hard disk space. I'm considering adding that to my early loader
> (iniload), debugger, and kernel. Most difficult would be the boot sector
> loaders due to space being at a premium there.)

That is a reasonable stopgap solution. In fact, it might even be supported already by some systems, depending on whether they truncate the LBA numbers to 32 bits.

> > 4. large file support (llseek, etc.)
>
> > Where it makes sense, existing specifications should be amended, but
> some
> > things may be better to redo from scratch.
>
> There's
> FAT+
> for FAT32 (and big-cluster FAT16) to store files up to 256 GiB - 1 B in
> size. (Up from the prior limit of either (commonly) 2 GiB - 1 B or (if
> using unsigned values) 4 GiB - 1 B). EDR-DOS is the only implementation of
> this yet.

Thanks, that is an interesting alternative. It does seem a bit too much like a hack.

My current idea is inspired by the old Linux UMSDOS. Basically, a specially named (eg. "FAT$EXT$.FS$"; could reasonably be marked as System and Hidden) and formatted (could even be human readable) file to store the additional data. It could exist in every directory where it is needed, or it could be stored in a single file, perhaps in the root directory. This file could also be used as a means to store other additional file properties such as long filenames or crypto-related stuff). In this scheme, large files would be stored as multiple regular files, each up to 2 or 4 GB in length.

For systems that don't support the scheme, command line utilities could be provided to access and manipulate the data file. The large files themselves could be accessed one chunk at a time using existing software.

A TSR could be written to add support for the scheme to existing systems. Alternatively, it could be supported directly through DJGPP and/or DOS extenders.

> And here's
> a
> description of EDR-DOS's llseek function 7142h. This interface, and
> corresponding seek offset and size field extensions in the SFTs, allows
> using 64-bit seeks.

Excellent.

-Albert.

> > 4. large file support (llseek, etc.)
>
> > Where it makes sense, existing specifications should be amended, but
> some
> > things may be better to redo from scratch.
>
> There's
> FAT+
> for FAT32 (and big-cluster FAT16) to store files up to 256 GiB - 1 B in
> size. (Up from the prior limit of either (commonly) 2 GiB - 1 B or (if
> using unsigned values) 4 GiB - 1 B). EDR-DOS is the only implementation of
> this yet.
>
> And here's
> a
> description of EDR-DOS's llseek function 7142h. This interface, and
> corresponding seek offset and size field extensions in the SFTs, allows
> using 64-bit seeks.

The dosemu2 MFS redirector supports large files now.

---
l

>
> > stored in the directory entry with the year represented as an unsigned
> seven bit number (0–127), relative to 1980, and thereby unable to
> indicate any dates in the year 2108 and beyond. The API functions defined
> to retrieve these dates officially only support dates up to 31 December
> 2099.
> > This will also affect the ZIP archive file format, as it uses FAT file
> modification timestamps internally.
>
> Not of immediate concern, but are there any solutions in sight here, maybe
> ZIP has one?

Doesn't VFAT implement ctime, mtime, and atime timestamps with second-granularity?

I don't know about .ZIP, as I've never studied it.

-Albert.