25 May
2020
25 May
'20
2:13 p.m.
I hadn't thought about IBMCACHE.SYS in *years*.??
I wrote it in
its entirety (there's even a patent that covers some of its operation).
I was in an AdTech (Advanced Technology) group at the time and
was looking at how to make disk operations faster in DOS at the time
when I came up with the idea. There was a *huge* battle within IBM on if
it should be released and in order to do so, it was fairly well
hidden.
I think that I recall a mention of REFERENCE disk of PS/2?
(NOT model 25 or 30, which didn't have extended memory)
Can IBMCACHE co-exist with HIMEM.SYS?
Or require it?
Or the A20 support needed by Windows 3.10?
When SMARTDRV was activated, did it disable IBMCACHE? or conflict with it?
Microsoft, with SMARTDRV, found out the consequences of write cacheing if
you don't teach or succeed in teaching people to do a proper shutdown.
SMARTDRV, in addition to being in DOS 6.00 was loaded and activated by
SETUP of WINDOWS 3.10. If a write error occured during Windows
installation, SMARTDRV had already prematurely reported successful write,
so there was no way to continue and go back and fix that file.
You could "RETRY" (with no success), "ABORT" and restart the
installation
with no DIRectory or files having successfully copied. But, you could NOT
"IGNORE" or "FAIL" and then go back and manually copy just the file
that
had failed. I was on the Win3.1 BETA; Microsoft support's response was,
"THAT is a hardware problem; not our concern". I suggested that NOT
dealing with it would be costly.
My solution was to place a dummy file (BADSECS.DAT) where the error was
(which neither SSTOR nor SPINRITE had been able to find.
Shutting off the machine prematurely, power glitch, etc. gave disk
corruption, which was blamed on disk compression, since that was the most
"VISIBLE" thing that users were aware of.
When my girlfriend went back to college, she would stand next to the
printer, with her coat on, pulling on the paper to get her homework out to
leave for class. She would hit the power switch of the computer as soon
as the paper came out. Failing to wait for SMARTDRV's write cacheing
corrupted stuff. In addition to write cacheing, SMARTDRV also optimized
the sequence of the writes, (it is faster to write all of the directory
sectors and then all of the data sectors, rather than bounce around
doing them in their original sequence) so sometimes she would get
DIRectory entries written without file content. "Ever since I installed
DOS6 with disk compression, I keep getting bad files!"
There was a media frenzy about "Microsoft disk compression currupts
disks".
Microsoft had to release free "Step-Up" from MS-DOS 6.00 to 6.20, then
6.21 (identical but without compression due to Stacker lawsuit), then
6.22 (same but with non-infringing compression.
The "repairs to disk compression" (which was never the actual problem) of
DOS 6.00 consisted of
1) not enabling write cacheing by default in SMARTDRV
2) IF write cacheing was enabled on the machine in SMARTDRV:
A) do not resequence the writes in SMARTDRV
B) do NOT display the DOS prompt when closing an application
program, until all buffers were written by SMARTDRV
6.2x also included patches to a few other long-standing problems.
--
Grumpy Ol' Fred cisin at xenosoft.com