The reason for these -zu compatible fixes is that in cases where SS is
not the same as DS (DGROUP) certain calls behave oddly, such as printf,
since the compiler is passing an offset on the stack where it assumes
DS==SS so the function receiving the parameters can use either segment
interchangeably. The problem is in certain circumstances (such as this
new interrupt handler) we are using the user's stack so the printfs only
work if that happens to be the kernel else you get random values. There
may be other cases where this occurs (I have experienced the printf
issue before when doing some win3 work in the int 2f handler, but did
not investigate at that time). I think Borland's compilers default to
DS!=SS (given I only saw an option to set DS==SS) so should not be an
issue for them.
I may have introduced issues when building with Borland's compilers, I
will fix them, but probably not until next week.
The basic gist of these commits are to handle int13h calls more like
MS/PC DOS does. In particular, MS-DOS hooks the int13h handler to both
fix some BIOS issues (about the only ones we may fix currently is if the
BIOS doesn't set carry on error, as we force it set and the BIOS must
clear, but additional ones can be easily added if needed), improve dma
boundary conditions (this is left in our int 25h/26h code), and allow it
to notice disk change even when a user program causes the BIOS disk
change status to be cleared. The latter is what this mostly fixes, if a
user program invokes any of the lower 0x16 subfunctions of int 13h (the
higher ones seemed not so important/BIOS disk specific/ and at least
0x16 must be watched) then the BIOS may report disk change and clear its
internal flag. Now when the kernel goes to detect a disk change, the
BIOS will report none and the kernel will most likely not notice. This
can be a tricky data loss issue to track down (one must know that one
of the programs they are running is calling an int13h function directly
and causing the BIOS to reset its disk change flag, and even then on a
change they would somehow have to force the kernel to recognize this).
So now we hook int13h with our own handler and on BIOS returning disk
change we go ahead and flag, so next query will see that a disk change
did most likely occur. Note though these changes will probably cause a
small (unnoticeable) slowdown on some Award BIOS based 386/486 (others?)
computers as it seems only certain int13h calls (such as disk read) will
clear the disk change flag causing the kernel to think the disk is
changed until it reads the BPB causing the flag to be cleared.
I also added (not fully tested) the int2Fh function 13h function that
allows one to install their own int13h handler while still letting the
kernel do its initial/post processing of int13h calls (failure to let
the kernel in on the processing could result in failed disk change
issues, unexpected DMA errors, all the other stuff the kernel normally
corrects, etc). This makes the kernel more compatible, including for
sneaky virus programs.
Jeremy
---
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click
___
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
