[Coco] Re: Disk Basic and 512 byte block floppies.

[John E. Malmberg]

In article <bup7tg$dpp$1 at sea.gmane.org>,
"Amardeep S Chana" <vxlzneo02 at sneakemail.com> writes:
>
> In the code you posted, the Disk Base Table (which is distinct from the BIOS
> Parameter Block and the Drive Parameter Block I referred to in another post)
> is directly modified in memory by the user program.  The Disk Base Table is
> a data structure of the BIOS disk driver implementation and is opaque;  i.e.
> not accessible via a published system call.

The official MS-DOS programming documentation for 2.x stated that the
recommended procedure was not to directly modify the Disk Base Table, but
to change the 0x1E vector to point to a local Disk base Table.  But that
changing these values was permitted.

With MS-DOS 3.x you had to modify the Table directly, changing the 0x1E vector
resulted in the application crashing with an access violation.

That is why I changed the program to modify it directly instead of the
supported method.  And it worked from MS-DOS 3.x, W95/98 and NT 4.0.

The book Undocumented DOS, explains that this access violation was caused
by a bug in MS-DOS 3.x and was fixed in 4.x and later.  In spite of it's title,
the book explains quite a bit about the documented interfaces.

But the fact that this bug was noticed in a printed publication indicates that
I was not the only one using that feature that got bit by the bug.

The only workaround was to modify the table directly.

> The implication of modifying an opaque data structure is that future
> versions of an implementation don't have to honor that method of accessing
> those parameters.  If there had been a BIOS or MS-DOS call that set sector
> size, it would still be available in any modern version of Windows because
> they support BIOS and MS-DOS system call compatibility.  _bios_disk() is
> still a valid call under NT, 2000, and XP but it doesn't actually use the
> BIOS to do the I/O (it uses the kernel mode diskette driver) so changing the
> table pointed to by vector 0x1E has no effect.

I may need to do a test to see if putting a new table in 0x1E as my version for
MSDOS-2.11 did will now work again, and then see if that also works under
Windows 2000 or XP.

In that case, I will have to have the program check to see if it is running
MS-DOS 3.X to work around that version specific bug.  Of course I currently
only have W95/W98/2000/XP to directly test with.

The documentation used to be better, and I have misplaced my original MS-DOS
documention of these calls.

I am pessimistic in thinking that changing the vector will as per the original
recomendations in the MS-DOS programming guides will make the program work on
Windows 2000.  As 3.X was a very popular release, and it broke a documented
method, so my guess if they broke the workaround, they broke the original
method as well, expecially since the documentation for using it has been
removed, while other information about similar API's have not been removed.

-John
wb8tyw at qsl.net
Personal Opinion Only