>> Simple: If you only use WIN /S then you can use the >> stable 2036 or stable 2038 kernel. The latter is on >> http://rugxulo.googlepages.com/ as binary snapshot. >> >> There are a few pending improvements before 2038 can >> be put on "sourceforge file releases"... The sources >> already are on sourceforge in our svn, of course :-) > > If there's a "stable" 2038, then that should get put on ibiblio for > general release as soon as possible. If it's on rugxulo's pages, then > very few people will know about it (heck, *I* didn't know about it - > see my other email.) > > 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 which two are already provided in source form. He doesn't exactly have to "wait" for these, we've completely described them. (The first one on the list, others in the FreeDOS bugtracker or old private e-mails.) Since it seems Eric doesn't exactly want to be the kernel maintainer, you need someone else for that. The mentioned patches are: - 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. - CALL 5 interface is broken, and probably crashes the system. 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 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've CCed the Freedos-kernel list, too. Regards, Christian ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
