[Freedos-kernel] notes about my recent commits (dev kernel only)
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
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel init-mod.h,1.56.2.4,1.56.2.5 prf.c,1.31.2.3,1.31.2.4 proto.h,1.75.2.7,1.75.2.8
Hi! 20-Ноя-2005 16:39 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: +++ prf.c 20 Nov 2005 16:39:14 - 1.31.2.4 @@ -123,17 +123,17 @@ +STATIC void do_printf(const char FAR *, va_list); +VOID VA_CDECL printf(const char FAR * fmt, ...); ^^ [...] -VOID VA_CDECL printf(const char *fmt, ...) +VOID VA_CDECL printf(CONST BYTE FAR *fmt, ...) ^^ Why? -VOID VA_CDECL sprintf(char * buff, const char * fmt, ...) +VOID VA_CDECL sprintf(char FAR * buff, CONST BYTE FAR * fmt, ...) -STATIC void do_printf(CONST BYTE * fmt, va_list arg) +STATIC void do_printf(CONST BYTE FAR * fmt, va_list arg) +++ init-mod.h20 Nov 2005 16:39:14 - 1.56.2.5 +VOID VA_CDECL init_sprintf(char FAR * buff, const char FAR * fmt, ...); +++ proto.h 20 Nov 2005 16:39:14 - 1.75.2.8 +VOID VA_CDECL printf(const char FAR* fmt, ...); +VOID VA_CDECL sprintf(char FAR * buff, const char FAR* fmt, ...); --- 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
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel intwrap.asm,NONE,1.1.2.1
Hi! 20-Ноя-2005 16:57 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: --- NEW FILE: intwrap.asm --- reloc_call_int13_handler: cli ; disable other interrupts for now INT instruction already disables IFlag. stc ; force error unless BIOS clears ?! This is issue of caller to set or reset CFlag. push dx ; store BIOS drive # for error handling usage push ds ; get segment of kernel DATA mov ds, [cs:_DGROUP_] pushf ; simulate int call so returns back here (flags+cs:ip on stack) call far [ds:_UserInt13] Bug!!! Here DS register is garbaged, whereas it used by some functions (for example, INT13/42). pop ds ; restore ds jc int13err ; test if error, if not return to caller int13iret: inc sp ; clean up stack inc sp sti ; ensure int's are renabled retf 2 ; return to caller leaving flags asis I don't think that this is right way, because caller may disable interrupts for own purposes, whereas here interrupts enabled. int13wrap: %IF XCPU 186 push ax ; preserve registers, setup stack frame push bp mov bp, sp mov ax, 13h; want to push 0x13 onto stack xchg ax, [bp+2] ; so restore pushed ax value and put 0x13 on stack pop bp ; clean up stack frame (leaving just 0x13 pushed on stack) pushbp pushbp mov bp,sp mov word [bp+2],13h pop bp --- 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
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel intwrap.asm,NONE,1.1.2.1
Arkady V.Belousov wrote: Hi! 20-Ноя-2005 16:57 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: --- NEW FILE: intwrap.asm --- reloc_call_int13_handler: cli ; disable other interrupts for now INT instruction already disables IFlag. stc ; force error unless BIOS clears ?! This is issue of caller to set or reset CFlag. push dx ; store BIOS drive # for error handling usage push ds ; get segment of kernel DATA mov ds, [cs:_DGROUP_] pushf ; simulate int call so returns back here (flags+cs:ip on stack) call far [ds:_UserInt13] Bug!!! Here DS register is garbaged, whereas it used by some functions (for example, INT13/42). good catch, I rewrote this section several times until I finally tracked down my problem was my usual init-time variables don't match run-time variables [address wise, though the compiler thinks they do, so the UserInt13 initialized wasn't the one used] unless special care is taken. Earlier versions had a different path for ah 17h versus ah 17h, which I need to re-add (as the error values returned do not make sense for most functions ah 17h, but even if not returned, still within same error code group for those less; that or just change it to check on int13/16h ) pop ds ; restore ds jc int13err ; test if error, if not return to caller int13iret: inc sp ; clean up stack inc sp sti ; ensure int's are renabled retf 2 ; return to caller leaving flags asis I don't think that this is right way, because caller may disable interrupts for own purposes, whereas here interrupts enabled. I'm not sure what is correct here, but I suppose it should simply leave the flag as the user had it (I think I added this after reading a note somewhere in RBIL about a bug in earlier BIOSes that failed to do this). int13wrap: %IF XCPU 186 push ax ; preserve registers, setup stack frame push bp mov bp, sp mov ax, 13h; want to push 0x13 onto stack xchg ax, [bp+2] ; so restore pushed ax value and put 0x13 on stack pop bp ; clean up stack frame (leaving just 0x13 pushed on stack) pushbp pushbp mov bp,sp mov word [bp+2],13h pop bp I like it, cleaner and removes the easy to overlook restoration of ax Thanks for reviewing these patches, 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_idv28alloc_id845op=click ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel intwrap.asm,1.1.2.1,1.1.2.2 kernel.asm,1.54.2.6,1.54.2.7
Hi! 20-Ноя-2005 19:03 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: +++ intwrap.asm 20 Nov 2005 19:03:17 - 1.1.2.2 -sti ; ensure int's are renabled retf 2 ; return to caller leaving flags asis Another potential bug: if caller will not STI somewhere after INT13, then it will work in CLI state (because its IFlag is CLIed by INT instruction). --- 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
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel intwrap.asm,NONE,1.1.2.1
Hi! 20-Ноя-2005 13:50 [EMAIL PROTECTED] (Kenneth J. Davis) wrote to freedos-kernel@lists.sourceforge.net: int13iret: inc sp ; clean up stack inc sp sti ; ensure int's are renabled retf 2 ; return to caller leaving flags asis I don't think that this is right way, because caller may disable interrupts for own purposes, whereas here interrupts enabled. KJD I'm not sure what is correct here, I suggest, only returned ZF/CF should be copied to existing value on stack. For example: int13iret: pushax lahf pushbp mov bp,sp and byte [bp+10],not 0C1h ; 10=bp+ax+...+cs:ip and ah,0C1h ; remain only SF/ZF/CF flags or byte [bp+10],ah ; pass to caller SF/ZF/CF from INT13 pop bp pop ax add sp,2 iret KJD but I suppose it should simply leave KJD the flag as the user had it (I think I added this after reading a note KJD somewhere in RBIL about a bug in earlier BIOSes that failed to do this). --- 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
