> Examples: > > - handling of floppy before disk is inserted / unformatted partitions > > - initdisk CHS geometry fix and BSS init fix from RayeR > > - int 21.1c non-FAT / non-existing drive handling fix from Tom
If anyone wants to contribute to discussions about this patches he can do now. >> seems Eric doesn't exactly want to be the kernel maintainer, you need >> someone else for that. > > Uhm you do not exactly motivate me I'm currently trying to. >> The mentioned patches are: > > None of those patches is necessary for the 2038 kernel Yes, if you want to add some "Known bugs" sections to the documentation instead. > but on > the other hand some of them are definitely useful, yes :-). > >> - Terminating self-owning PSPs (parent PSP field set to the PSP) doesn't >> work. There's a patch for this in inthndlr.c but it's wrong and leads to >> crashes. The patch in inthndlr.c (below case 0x4c of the main Int21 >> handler) has to be removed, and the condition of a self-owning PSP has >> to >> be handled like a TSR termination in the return_user function in task.c. >> 2037 is affected by this, too. > > Afair, self-owning PSPs happen in shells and in DEBUG etc, but > I do not remember having problems with leaving DEBUG. DEBUG (at least FD DEBUG and derived versions) avoids accidental termination by any means. The only real possibility is that somehow a critical error occured when DEBUG's PSP was active, and the default answer of "Fail" returned by DEBUG was turned into "Abort" because "Fail" wasn't allowed on this particular error code. This is very unlikely, in fact I don't even know any error code that doesn't allow the "Fail" response. So, DEBUG's patched PSP is mostly just a backup if something goes wrong but will usually never be used. > Leaving > the main SHELL is not a good idea anyway. But works well in other DOS versions. > Plus the origins of > your inthndlr.c / task.c patch are a bit fishy copyright-wise. Just like UDOS and the documentation of DOS-internal data in RBIL are. You know, you might just ignore my patch and add that as a known bug. >> - CALL 5 interface is broken, and probably crashes the system. > > Note that only CP/M programs use this, software from the seventies. Yes, and DOS is mainly software from the eighties and nineties ;-) >> The Assembly code in entry.asm that handles such calls is screwed >> up. I can provide working replacement code or patch it to work how >> it's supposed to. 2037 is affected by this, too. > > The patch was long ago and I remember the discussion about it > was aborted too early. It should have been on the list, too. > I believe it was a "do what I say or forget it" request ;-). Might have been too rude there, or haven't explained it enough. As mentioned in my previous mail, I could patch the existing code instead. >> - The seek position (and various other fields) of the SFT isn't declared >> as unsigned. Eric reported that the seek function reports errors using >> negative return values. This has to be changed so that it can work with >> files up to 4 GiB. Depending on when the seek function is called >> (whether >> it's already determined that the handle references a valid SFT, and that >> the origin in al is valid) you might just remove any error reporting of >> it, since the actual seek operation never returns errors in MS-DOS (as >> mentioned in RBIL and UDOS too). 2037 seems not to be affected by this, >> at >> least the case 0x42 in inthndlr.c should work with larger seek >> positions. > > I agree that supporting files above 2 GB size is high on the > wishlist and reasonably easy to implement. Will work on it :-) Thanks! >> I've CCed the Freedos-kernel list, too. > > Okay, so I guess I have to CC both lists, too :-) Since we're getting more into the tech stuff now, I think I can reasonably mail this reply to the kernel list only. Regards, Christian ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
