Disklib extracts to get you started...

Hi, as recommended by Imre, I have downloaded
http://www.diskwarez.com/disklib.htm -> disklib.zip ...
It contains 16- and 32-bit and DOS and Windows versions of
BIOS / IOCTL / Windows / DOS raw disk access. As DOSFSCK will only use
32bit mode and does not assume Windows to be present, I have stripped
everything else and came up with:

http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/disklib.c

This offers 3 versions of reading and 3 versions of writing. See
Ralf Browns INTLIST for further details. I have tried to fix a bug
in FAT32 write access. I THINK that the OTHER functions do NOT work
as you are supposed to use CALL FAR to where the int 25/26h vector
points to and not INTerrupt!

So please consider disklib.c as being "completely broken", BUT only
a few patches away from working!

http://www.delorie.com/djgpp/doc/libc-2.02/ ->
http://www.delorie.com/djgpp/doc/libc-2.02/libc_249.html
(int __dpmi_simulate_real_mode_procedure_retf(__dpmi_regs *_regs);)
is probably better there...

See http://www.delorie.com/djgpp/v2faq/faq24.html as well...
By the way, __dpmi stuff gives DOS a stack automatically if you set
ss and sp in the _regs structure to zero, so you do not need to provide one.


I think you can just call disk_read -> disk_read_ext -> disk_read32 in that
order, use the next one if the first fails. Alternatively, be nice and
use INT 21h to detect the partition size first: If > 32 MB, use the ext
version. This will get an error message on Windows 9x ("direct disk access
attempted"), so better call the read32 version first. Drive numbers are
one-based (1=A: and so on) for read32 and zero based (0=A:) for read and
read_ext, so be carefull !!!

Well, you get the point. Try to be nice and determine the correct style
of call to be used before using it. NOTE that read32 and write32 already
fix the zero-based / one-based problem internally, so you do not need to
add that...

TODO LIST:
- determine which call to use, based on partition size and type. Use INT 21
  functions for that. Not really needed: read fails with AX = 0207h if you
  need to use read_ext, Windows uses 0408h to say that you may retry with the
  drive number + 128.... I recommend this order:
  Use read32 -> fails? -> use read if sector number < 64k, use read_ext
  if read has failed or sector number > 64k.
  My undelete, which does not use FAT32 at all, simply calls read_ext if
  sector number is > 32767, which is probably wrong. Sorry about that.
  If you need to access a drive of 16..32 MB of size, please correct the
  code in diskio.c of undelete from INT_MAX to UINT_MAX.
  It does not even retry with the _ext version, although some drivers are
  said to only accept the _ext call even for the first sectors of a > 32 MB
  drive. Probably a service of our KERNEL :-).

- pack this into a wrapper: readsector(drive, buffer, count), which branches
  to the right style of call. May use a global 32 entry array that gets
  initialized by opensectors(drive) if you want :-). For dosfsck, even a
  single set of variables is enough: Store the style and the drive number
  on opensectors() and just write a readsector(sector, buffer, count)...
  (Oops, I forgot "sector" above :-)).

- pack the wrapper into a wrapper: dosfsck wants to read big and small,
  not sector-aligned chunks of data. Classic problem, should be not too hard.

- edit io.c: fs_open, fs_read, fs_write, fs_flush, fs_close must be adapted
  to use the new functions instead of llseek, read, write, open, close, but
  ONLY if a path of style "x:" was used in fs_open! Please read io.c
  carefully and try not to break the functions for "filename" style access!!
  Also, be careful not to break the "write only if write_immed, otherwise
  wait until fs_flush with writing" functionality as this is very useful.

- test the program. You may want to disable writes completely for first
  tests, by patching fs_write (if done right, fs_flush does not have to
  be patched).

I hope this gave all of you enough inspiration to get this stuff done,
I certainly do not have the time right now. Some feedback about my
analysis that the DJGPP version of disklib is mostly broken would be
nice as well. But remember, fixing it should be relatively easy.

Cheers, Eric