The DOS 3.3 Sys.com Bug Hunt

> I am a little bit freaked out by that because the pointer to the buffer is set before the IOCTL call; the code knowingly sets a pointer to a buffer into what looks like its code area. Let's hope they knew they were done with that part of the code, or it's just another interesting bug to dissect.

This is common in code without segmentation protection. CODE and DATA are convention. You can just specify a function, then a small buffer, then another function. .COM files in particular were easier to write with CS and DS pointing to the same region of memory, assuming you could fit both your code and inline buffers in 64kB.

The code explains what they are doing. Even more interesting, they're using their own stack too:

  ;  1 - This program uses its own internal stack.  The stack space provided
  ; by DOS is used as an input buffer for transfering IBMBIO and IBMDOS.
  ;
  ; SYS is linked with the CODE segment followed by the DATA segment. The
  ; last symbol in DATA is BUF. It marks the end end of data and the
  ; start of the BUFfer.  The BUFfer extends from here to SP.  The first
  ; 6.5Kb (13 sectors) in BUFfer are used for up to 12 sectors of the FAT
  ; or the directory. In Main, the remaining space is set
  ; as follows:
  ;        cdBuf = SP - ( FAT_BUF + BUF )
  ;

To use an LBA HDD or especially a SSD as well as DOS can, I've always found that the DOS from W98SE, with the 2001 update, is about the most reliable.

The only repeatable way when ongoing testing is underway is to zero the media each time, since many times DOS will rely strongest on what is already there during a Format or SYS. So will every version of Windows, but without full consistency at all.

If using Win10 or 11, you may find that even with a zeroed floppy or HDD partition when you power off, the partition will be silently formatted just as Windows last remembers it when you reboot, transparently without notice.

Plus even with successfully zeroed media, there is often a difference in what the Format comes out like depending on whether you booted the PC to an actual floppy, HDD, or SSD, and what their geometry was. And this can often come out different on different motherboards because of their dissimilar bios recognition of what the geometry is and what will be compatible with potential booting on that particular device.

Other times it seemed like some bioses were not suitable for formatting some media well enough to be bootable on their own device. But worked just fine if formatted on a more "universal" motherboard, then boot fine on the problem PC.

These days I want my FAT32 volumes, which are often being used as boot volumes as expected under UEFI, to be fully formatted under DOS for best reliability. None of the intentionally lesser stuff ever since. But I also want my structure to align with 4096 byte sectors which really helps with AF HDDs and SSDs. DOS won't do this on its own. Plus Windows mostly defaults to putting the bootsector at 2048 now instead of 63 on LBA gear, so I format a zeroed FAT32 partition using Windows 10 or 11 first. Then to the disk editor where everything is re-zeroed except the bootsector and the following 8 sectors. Edit the bootsector & backup bootsector (6 sectors later) for 2048 Hidden Sectors. And 2048, 4096 or a multiple of 4096 Sectors Per Fat, depending on which multiple is closest to the value that was there by default (according to the size of the partition) when there was no awareness of SSDs.

Then back to DOS and Format /Q, on a good motherboard it will retain the values you edited in, and you've got a more reliable foundation for your boot files or anything else.

I'm surprised to find I feel disappointment he didn't provide a patch to fix it.