Int 13h buffer 64k boundaries

[Chuck Guzis]

On 04/18/2018 09:20 PM, Fred Cisin via cctalk wrote:
>>> I always found it amusing that many programs (even FORMAT!) would fail
>>> with the wrong error message if their internal DMA buffers happened to
>>> straddle a 64K block boundary.  THAT was a direct result of failure to
>>> adequately integrate, or at least ERROR-CHECK!, the segment-offset
>>> kludge
>>> bag.  Different device drivers and TSRs could affect at 16 byte
>>> intervals
>>> where the segment of a program ended up loading.
>>> It was NOT hard to normalize the Segment:Offset address and MOVE the
>>> buffer to another location if it happened to be straddling.
> 
> On Wed, 18 Apr 2018, Charles Anthony wrote:
>> Huh. I would guess that this is the source of a DOS bug that I found back
>> in the day, reported to MS, and never heard back.
>> . . . A buffer boundary straddling error certainly sounds like the
>> issue I was
>> seeing; it feels very odd to see a plausible explanation 35 years later.
> 
> I'm learning a lot these days that would have been handy back then!
> 
> Segment:Offset hides it until you normalize the resulting address.
> IIRC, INT13h should return a code of 09h if the DMA straddles a 64K
> boundary.
> But, not all code checks for that, or knows what to do when it happens.
> Looking at the value of ES:BX? can work, or, if it happens, swap your
> DMA buffer with one that is not used for DMA (and doesn't happen to be
> 64K away :-)  In my code, I happened to have buffers for several
> purposes, so that was easy to do.
> If operating above Int 13H (DOS calls), then you are dependent on DOS
> error checking.  "Can you trust THAT?"
> If operating below Int 13h, then be careful where your DMA ends up, work
> without DMA, or simply watch for occurrence.
> 
> And, of course, a lot of C code can't tell the difference between end of
> file and a disk error.
> #define EOF (-1)    /* depending on implementation */
> while ((ptr2++ = fgetc(fp2)) != EOF); /* does not differentiate between
> error and end of file */ fgets() returns a null pointer for EITHER
> end-of-file OR error!
> and therefore assumes total reliability and any failure to read is
> assumed to be EOF.
> IFF available, feof(fp2) is much better.
> 
> 
> You certainly did the right thing, narrowing it down to load address. 
> The final conclusion would have been to systematically try many/all load
> addresses, and see whether it was consistent for given ones, and what
> the failing ones had in common.
> 
> Yes, the "solution" for the extraneous FORMAT failure was "add or remove
> TSRs and device drivers"!
> 
> When I first hit it, I used a P.O.S.T. card, and put in minimal code to
> output values until I realized that DS was the key, and that I had
> mishandled error #9.  Eventually I realized that even for code not my
> own, I needed to write a TSR intercepting Int 13H calls.
> (For exampole, the critical error handler in certain early versions of
> PC-Tools was more concerned with protecting their pretty display than
> success of writes!)
> 
> 
> Microsoft's response to error reporting was amusing.
> 
> I was in the Windows 3.10 Beta, and encountered the SMARTDRV write
> caching problem.  There was apparently a flaw on one of my drives, that
> neither SPINRITE nor SSTOR could find.  But, during Windoze
> installation, a write would fail, and with write caching ON (Windoze
> installation did NOT give you a choice), there was no way to recover
> from a write error!
> (SMARTDRV had already told SETUP that it had been successful, so now,
> when the error occured, there was no way to (I)gnore the error (figure
> out which file copy had failed, rename the failed copy "BADSECS", and go
> back later to copy that one manually).  All you could do was (R)etry
> which didn't work, or (A)bort, which cancelled the entire setup before
> it ever wrote the directory entries for the files that had worked. By
> loading a bunch of space filler files on the disk, I was able to get the
> installation to be in a working area.
> Once I finally determined WHERE the bad track was, I put in a filler
> file to keep it from being used.  (SPINRITE tried to return it to use
> when I just marked it as BAD!)
> 
> Microsoft's response was, "YOU have a HARDWARE problem.  NOT OUR PROBLEM."
> I was unable to either convince them that CORRECT response to a hardware
> problem was a responsibility of the OS, NOR that SMARTDRV with
> write-caching was going to cause a lot of data losses that they would
> get blamed for, inspite of it not be narrowed down to SMARTDRV, and that
> it would end up costing them a lot.
> 
> Sho'nuff, COMPRESSION got blamed for the data losses.
> 
> DOS 6.2x had to be put out for FREE to fix "the problems with compression".
> The "problems with compression" were fixed by having SMARTDRV NOT
> default to write caching ON, have SMARTDRV NOT rearrange writes for
> efficiency (it wasn't writing DIRectory sectors until later), and having
> SMARTDRV NOT returning a DOS prompt until its buffers were emptied.
> (One of the common losses was people would save a file, and turn off the
> computer as soon as the word processor came back to the DOS prompt.
> SMARTDRV had not finished writing their file!  When my girlfriend went
> back to school for some classes, she would stand with her coat on,
> pulling on the paper as her homework printed, then kit ^KD? and turn off
> the computer.)
> 
> I was not invited to be in the 3.11, nor WIN95, Betas.
> They wanted cheerleaders, not testers, anyway.
> 
> -- 
> Grumpy Ol' Fred             cisin at xenosoft.com
> 
> 


-- 
--Chuck

Sent from my digital computer