CSTROM%mit-mc@sri-unix.UUCP (03/10/84)
From: Charlie Strom <CSTROM@mit-mc>
I received a clarification of the infamous BDOS 37 bug in CP/M 2.2 by
way of Compuserve's CP/M Interest Group. Following is the straight
poop (or so I am told)...
Fm: Jim Rosenberg 71515,124
To: All
Several months ago I left a message here about the bug in BDOS function 37. I
see Jerry Pournelle is sounding off about it in this month's BYTE, and
he's got his facts all mixed up. For those who missed my earlier message,
here's the story as I know it.
There is definitely a bug in BDOS 37, which will get you into deep trouble
if you don't know about it, but if you use it carefully it seems to be
perfectly safe. The problem comes when function 37 is used to reset the
current default disk. Function 37 seems to do nothing but reset the correct
bits in the login vector. Evidently BDOS simply assumes that the current
default disk CAN'T fail to be logged in, and when that happens it gets
extremely confused. (Don't try to debug the results if you value your sanity!
I've seen open calls on a completely different disk report a file doesn't exist
even when it does, and the allocation map of the FCB is filled in by the open
call!!) My experience is that function 37 is perfectly safe if you aren't
resetting the current disk. (I've only used it to reset one drive at a time.)
The algorithm to reset an individual drive with the least pain is: (1) do
BDOS 25 to get the current disk. If that isn't the drive you are resetting go
ahead and use BDOS 37. (2) Otherwise, get the login vector (BDOS 24) and see
if some drive other than what you want to reset is logged in. If so, select
that drive, use BDOS 37, then select back to whatever drive had been current.
(3) Only if neither of these obtains do you need to use BDOS 13.
If anyone finds this doesn't work please let me know. I've used this
algorithm in a piece of software of which I've sold hundreds all over the world
and it seems to work. -Best, Jim
P.S. This is 2.2!! Don't know if it also applies to CP/M-86.