Hi Christian, >> If you're waiting for further improvements to 2038 before you release >> 2038, then you're doing this wrong. [...] I'd strongly recommend >> making 2038 available, and putting the "few pending improvements" in >> 2039. > > The problem is that Eric holds back at least three necessary patches, of
There are also patches waiting for feedback / review / testing. Saying you have to modify this like that is one thing, discussion is another. 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 > seems Eric doesn't exactly want to be the kernel maintainer, you need > someone else for that. Uhm you do not exactly motivate me but I can repeat the state of things: The 2038 kernel needs mainly doc updates plus some feedback for a few small pending patches. The lists are too silent on that. Of course I could just push the patches and assume they will work, but that is the non-preferred choice. > The mentioned patches are: None of those patches is necessary for the 2038 kernel 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. Leaving the main SHELL is not a good idea anyway. Plus the origins of your inthndlr.c / task.c patch are a bit fishy copyright-wise. > - CALL 5 interface is broken, and probably crashes the system. Note that only CP/M programs use this, software from the seventies. > 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 ;-). > - 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 :-) > I've CCed the Freedos-kernel list, too. Okay, so I guess I have to CC both lists, too :-) Eric ------------------------------------------------------------------------------ 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
