Direct disk access in DOS

This is a discussion on Direct disk access in DOS within the A Brief History of Cprogramming.com forums, part of the Community Boards category; I'm writing a small disk utility that will allow the user to view the bootsector, bootstrap, partition tables, FATs, and ...

Direct disk access in DOS

I'm writing a small disk utility that will allow the user to view the bootsector, bootstrap, partition tables, FATs, and also browse their drive sector by sector.

I'm using the INT 13 API under Win98SE but Windows is continually blocking my INT 13 calls so that all registers return 0's. I've even issued the Lock Physical Volume INT 21h, subfunction 484Bh, to lock the volume so I can directly access the disk. Still no go. Windows will not even let me get the drive parameters for the drive so it is impossible for me to even do CHS or CHS to LBA translation on the drive.

Does anyone know how to tell Windows to lock the volume so that I can directly access the disk (hard disk - floppies will work). I really need this information and I've done a lot of research but none of the pages talked about this problem.

When I issue Lock Physical Volume to DOS 7.20 I get 0005h in AX which means ACCESS DENIED. I have to tell Windows to take a hike before I can access the drive. Please help.

What compiler you use? I have turboc++ 3.0 which is for DOS only. If you are using vc++ or c++ builder, I think then you are only making console applications. I highly recommend getting turboc++3.0 for dos utilities. I'm pretty sure this will fix your problem. Keep me updated. I'm trying to design a hex viewer(later on, an editor also) for a boot disk.

I could use BASIC for all it matters. I'm just calling the INT 13h MS extensions to gain access to the drive. That can be done in any language. This is not a language problem and it is not a console app. This is a DOS app.

The only problem is that MS Windows has patched into the INT 13 chain so that it can intercept viruses and other harmful programs that can damage the FATs, boot sector, boot strap, etc. It is intercepting my INT 13 and discarding it. I wish I could patch into the INT 13 chain, and then patch into the former INT 13 prior to Windows patching it - but since I don't know where or even if MS Windows saved the previous vector, I cannot do that.

My problem is this:

BIOS Disk Services -> INT 13 -> MS Windows

Windows is guarding the INT 13 so I cannot use it. I have to lock the phyical volume (similar to command line LOCK) in order to do this. But I'm calling INT 21h to lock the physical volume but even that is telling me access denied. So if MS Windows will not let me lock the volume, there is no way I can gain access to it.

but I do not know where or even if MS Windows saved the previous vector. I would have to patch the bootstrap code to get the original INT 13 vector prior to Windows installing its handler on INT 13. But I cannot patch the bootstrap cuz of my problem. It's a catch 22.

I could also just find out where in memory the BIOS code resides, but I don't think that is constant for all BIOSes.