Hello Eric,
> DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of
> a NULL navc pointer.
If so, please submit some code to make the kernel crash.
if not, shut up.
> I wonder if it is really desirable that the
> current implementation fakes bigger cluster sizes to allow cluster
> counts below 64k
Probably Bart implemented it for sheer fun ?
> Maybe saturation would be better. How do other DOSes handle this?
maybe would be better that YOU check other DOS'es behaviour BEFORE
writing emails, because you are just bored ?
> For drives beyond lastdrive, get_cds result protects from crashes,
> but in between, access to unformatted disks returns nonsense for
> int 21.36 and even crashes while trying to do critical error dialog
really ?
please provide exact code sequence where it DOES return nonsense - and
I'll fix it. (we are talking about ke2035 !!)
> for int 21.1c - probably some 0:xx data or stack got overwritten.
please provide exact code sequence where it DOES overwrite something -
and I'll fix it. (we are talking about ke2035 !!)
> LBA_Get_Drive_Parameters should NOT disable LBA access if heads or
> sectors are > 64k
As I wrote this:
if sectors or heads are > 64K the LBA BIOS is probably buggy.
and IMO it's better to refuse to work with a buggy BIOS then to
try to trash a users disk.
> or if totalSectHigh is nonzero.
this will be relevant when disk (arrays) are larger then
2 TB (not that far away)
but then we good old partitioning scheme stops to make sense,
and it's better not to touch these disks at all.
there could be some (easy) workarounds for that (my estimate less
then a few hundred resident byte) + understanding dynamic disk
partitioning (non resident code).
until that is done it's a better idea not to touch these disks.
> At several places, "ULONG / value" and "ULONG % value" could be
> explicitly marked as "ULONG / UWORD" and "ULONG % UWORD" type,
> to allow compiler optimizations (32:32->32 bits is more complex
> on 8086 than 32:16->32 bits).
as was relied before (but you are probably so busy writing emails
rather then reading) :
there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32.
end of story.
> LBA_Transfer should call the appropriate int 2f.xx function before
> calling play_dj - or play_dj should call it itself:
which 2f.xx functions please ?
> For the latter two, I recommend:
> If buffer is exactly aligned, transfer limit should probably be
> 64k, not 64k - 1 sector.
nonsense. you simply cant issue a read request to DOS > 0xffff
> Track wrap protection and DMA wrap
> protection should be turned off (maybe add a SYS CONFIG variable!)
> for harddisks.
nonsense again: there's a specific field in EXT13 functions, if DMA
crossing is allowed or not (and the kernel doesn't care about it)
doesn't make a difference anyway.
> There is also UMB avoidance: If a buffer is in
> UMB or HMA, all access is copied through the low RAM disk transfer
> buffer (which is only 1 sector big). Probably required,
definitively for EMM386 style UMB's (lacking Virtual DMA support)
on some UMBPCI machines
> but should be mentioned in kernel docs (<-> DEVICEHIGH/LOADHIGH).
which kernel docs ?
tom
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
