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 did. Read and shut up: > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/format/format-0.91r.txt do you really expect me to occasionally search for such texts ? I haven't seen any such report on the kernel list, or in bugzilla yes - it contains indeed code that crashes the kernel although it's for DOSEMU and the optimized ke2035a, I'll check in a real machine with ke2035; if that crashes as well, it'll be fixed soon. 1 hour later: I checked that. what I did: I have a drive, that is definitivlely not proper formatted, and if I say DIR K: I get some Abort/retry/fail dialog. I tried this with the mentioned (format-0.91r.txt) functions 21.36 and 21.1c I don't know if the behaviour is the same as in MSDOS (returning carry set or not, returning same register values etc.), but at least ke2035 on real hardware behaves completely *reasonable* and does not crash. while I won't buy you another DOS (you destroyed your own copy of MSDOS yourself and on purpose), you CAN get ke2035, and you CAN test it on real hardware. >> > Maybe saturation would be better. How do other DOSes handle this? >> maybe would be better that YOU check other DOS'es behaviour BEFORE > Buy me another DOS or shut up. just assume that the people who wrote this code compared it to other DOS's while writing it (I know). so buy another DOS or shut up >> please provide exact code sequence where it DOES return nonsense - and >> I'll fix it. (we are talking about ke2035 !!) > That translates to: Provide a fix and you will have provided a fix. Helpful. I intended to say (as above, but didn't exactly say it): provide some sort of mov ax,XXX mov dx,YYY int 21h --> misbehaviour (wrong return value, crash or just reboot) and the cavalry is set into march >> there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32. >> end of story. > Compiler weakness :-P. compiler facts >> > 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. > I vote for: Then you better only use the first 2 TB. I vote for: wait till 2TB disks arrive. see. possibly fix bugs. THEN remove this. > And you will probably have only a fraction of the DOS > partitions reachable at all if you drop to CHS mode. if you understood the new style partitioning scheme, you'd know that you'll have NO partition available for DOS anymore. >> > 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... > I know that you cannot detect this. I can detect this. > BUT on the other hand I believe I measured - it's irrelevant. > that turning off track wrap protection and maybe also DMA wrap protection > can help to significantly improve performance, so it's not worth the effort. 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
