>> 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
> 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.
- 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 :-)
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.
Freedos-user mailing list